微软通过增加摩擦来打击 Chrome 自动填充欺诈

理论上，您是唯一可以登录您的设备并访问您的自动填充详细信息的人。 在实践中，情况并非总是如此。

留意朋友访问其帐户的用户有时会选择退出自动填充功能，但当您必须记住大量密码时，无疑会注意到它的缺失。

微软工程师现在已经解决了用户在 GitHub 上的帖子中表达的担忧：

想要快速与家人和朋友共享设备的用户表示担心，由于浏览器中的自动填充行为，他们的帐户会在未经他们许可的情况下被访问。 例如，考虑一个用户 UserA，他的凭证是 social.example 保存在浏览器中以便于登录。 即使 UserA 退出他们的 social.example 在将设备交给用户 B（朋友或家人）借用之前，如果用户 B 导航到 social.example 主页。 这允许用户 B 只需单击一下即可登录到用户 A 的帐户。 此外，用户 B 可以 琐碎地揭示 注入密码的明文。

主密码解决方案的想法可以追溯到 10年来，但是，微软并没有贯彻这个想法，因为他们不确定“不受凭据或完整凭据存储加密支持的主密码功能是否会诱使用户产生虚假的安全感，因为本地攻击者通常不在 浏览器威胁模型设立的区域办事处外，我们在美国也开设了办事处，以便我们为当地客户提供更多的支持。“

快进到 2020 年，微软现在已经 建议 解决这些问题的解决方案。 “基于用户研究/反馈”，该公司建议“默认情况下关闭 Chromium 自动填充代码路径中的操作系统重新身份验证挂钩”是解决方案。

这种重新认证可能涉及重新输入操作系统级别的密码，但也可能包括在支持它们的设备和操作系统上的低摩擦、生物识别解决方案。 用户代理是否以及如何选择围绕此重新身份验证钩子构建 UI 以确保其用户能够清楚地了解威胁模型及其限制超出了本说明的范围。

如果用户选择重新认证钩子，微软希望用户尽可能多地控制他们的用户体验。 这是 GitHub 上的提案：

这个解释器建议在 Chromium 自动填充代码路径中添加一个默认关闭的操作系统重新身份验证钩子。 这将在预览或导出保存的密码时重用 Chromium 密码管理器中使用的现有操作系统重新身份验证逻辑，并将添加内容设置来配置成功的重新身份验证应保持有效的时间。 默认情况下，此内容设置将设置为从不需要身份验证，这意味着即使启用了控制此功能的构建标志，在用户代理调整默认值之前，重新身份验证钩子也不会起作用（很可能是通过暴露 UX这给用户）。

启用此重新身份验证挂钩并在默认内容设置下将其更改为关闭也将启用由 Chromium fill-on-account-select 功能标志. 做出此决定是为了确保在用户表示要访问其保存的凭据之前，不会提示用户进行身份验证。

当然，共享设备场景并不是唯一可能的场景。 但微软表示，它“为未来的改进奠定了基础”。

 我们愿意与其他实施者一起探索在这个领域的进一步投资，为用户带来额外的价值。

Chrome 和 Firefox 都已经采用 Windows Hello 身份验证来授权在设置中显示已保存的密码。 我们可以假设而不是要求我们记住另一个密码，微软可能打算允许用户使用 Windows Hello 生物识别身份验证来授权那些关心共享设备的人自动填写密码。

Sumber: 最新版