防网络钓鱼短信自动填充(译文)
By S.F.
本文链接 https://www.kyfws.com/news/2020-09-25-phishing-resistant-sms-autofill/
版权声明 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
- 5 分钟阅读 - 2378 个词 阅读量 0防网络钓鱼短信自动填充(译文)
原文地址:https://github.blog/2020-09-25-phishing-resistant-sms-autofill/
原文作者:Zhongying Qiao
译文由本站翻译
我们最新发货支持[原产地标准预算](https://wicg.github. io/sms-one-time-codes/)表示通过SMS传送的安全代码.该标准确保以防网络钓鱼的方式输入安全代码.它通过将SMS与发送站点的来源绑定来实现此目的.此外,该标准定义了一种格式,该格式可使安全代码更易于浏览器和应用程序解析,并且不需要启发式方法来支持自动填充.
苹果在iOS 12中引入了安全代码自动填充功能.启用了短信转发功能后,自动填充功能也可以在macOS Mojave的Safari上使用.此功能非常适合用户体验:
- 在其GitHub帐户上配置了SMS的人输入其用户名/密码.
- 他们会收到包含其安全代码的SMS,并会提示您填写安全代码.
- Safari会自动在登录表单中输入代码.
- 他们单击"提交"并登录.
iOS 12/macOS Mojave随附的自动填充功能确实使用了原点绑定标准.结果,Apple必须使用多种试探法来启用自动填充.这些启发式方法使SMS自动填充易受用于欺骗人类的相同类型的网络钓鱼攻击的攻击.
让我们快速了解一下SMS自动填充之前传统上会发生这种网络钓鱼攻击的方式.
- 有人访问https://not-github.example,看起来很像https://github.com .
- 他们输入用户名和密码.该用户名和密码将发送到https://not-github.example,然后将这些凭据输入到https://github.com(经典的中间攻击者).
- 要求他们输入刚刚通过SMS推送到其设备的安全代码:" 123456是您的GitHub身份验证代码."
- 此人未意识到自己位于恶意站点上,便着手将代码手动输入到https://not-github.example中,最终将安全代码提供给了攻击者.攻击者自己输入代码,现在以用户身份登录到GitHub.com.
安全代码或多或少是自动执行自动执行步骤4的步骤,其中用户手动将SMS代码输入到https://not-github.example中.启发式方法用于_承担_,如果收到文本并且看起来像是安全代码,则用户可能希望将该代码填充到设备活动窗口中的输入框中.从网络钓鱼的角度来看,它基本上不比手动输入好或差.
SMS安全代码网络钓鱼的核心问题是无法将SMS的发件人绑定到应该使用它的站点.苹果公司意识到,仅对发送给用户的SMS消息进行很小的更改,这似乎是一个非常棘手的问题.起源限制规范建议站点修改其SMS安全代码消息,以包括"页脚",该消息的最后一行以标准化格式包含有关发送站点的起源信息以及安全代码本身.对于GitHub,我们的安全代码消息如下所示:
123456 is your GitHub authentication code.
@github.com #123456
这个简单的添加可以阻止网络钓鱼攻击,因为自动填充逻辑可以确保仅在GitHub.com上自动填充代码.如果用户当前使用的是https://not-github.example,则浏览器将拒绝自动填充安全代码.从技术上讲,此信息也可以由人工手动输入代码的人使用.但是,计算机非常擅长遵循简单的规则,准确率接近100%.另一方面,人类在这种事情上非常糟糕.研究表明,用户对网址感到困惑.这不是他们的错;用户被迫处理URL以使用Internet,但是期望这些用户全面了解与之相关的微妙安全模型是不合理的.
谁支持它?
苹果是该规范的原始作者,是即将发布的iOS 14和macOS Big Sur的第一个实现者.但是,这不是Apple专有的标准.起源约束标准也是Google最近提出的Web OTP API的基础.该提案旨在标准化SMS安全代码在客户端中的提取和自动填充方式.即将推出的Apple实施使用起源限制标准,但是实际的自动填充实施是专有的,并且仅适用于Apple自己的浏览器/设备. Web OTP API提出了平台所有者可以支持的标准化JavaScript API.到目前为止,该建议仅在Android上实现,但是我们将继续监视情况,以查看该建议是否以及何时获得更广泛的采用.
是SMS"安全" ?
在总结之前,我们想讨论最后一个相关主题.一些阅读这篇文章的人可能会发现自己在问:“为什么GitHub谈论SMS作为多因素凭证并对其进行额外投资?短信是否损坏/不安全/等?”. SMS确实是不可渗透的.面对SMS时,SMS不如其他一些选项(GitHub.com支持所有这些)那样有弹性.有针对性的攻击.但是,有一个原因是GitHub以及拥有精明安全团队(包括Apple)的许多其他站点继续支持SMS的原因. 当前数据支持SMS仍然非常有效地抵御最常见的攻击.
结论
安全性和可用性通常相互矛盾.虽然SMS不如其他一些多因素选项强大,但SMS可以很好地抵御最常见的攻击,并且在可用性方面非常强大:无需安装任何应用程序,可以从掉入海洋的设备中恢复,等等.GitHub一直在不断发展查看帐户安全状况,以评估SMS适合的位置以及哪种新兴标准最终可以补充甚至取代它.我们对新兴的WebAuthn安全标准感到非常兴奋,因为它似乎提供了难得的机会,既可以极大地提高安全性,又可以使所有人都变得异常容易(尤其是"平台身份验证器",例如Face ID/Touch ID,Windows Hello等).但是,该标准仍处于起步阶段.我们一直在跟踪并希望看到如何利用WebAuthn来提高安全性和可用性.同时,我们将继续寻找可以改善现有选件安全性的方法.与源绑定的安全代码SMS交付就是其中一项改进,它需要相对较少的投资来获得所提供的安全利益.
Security 新闻 翻译