☰

oAuth 如何更安全？

tag-icon • tag-icon security oauth2
oAuth 如何更安全？

许多服务，例如 Google 的 IMAP 邮件，已经不再使用用户 ID/密码验证，而是使用 oAuth。

除了 oAuth 是由一家拥有更多资源进行监控的大型公司提供的服务之外，它如何更安全？

答案1

技术优势包括：

  • 由于 OAuth 的“初始身份验证”部分是通过网站完成的，因此除了密码之外，它还可以更轻松地要求提供其他身份验证因素。例如，它可以要求提供 TOTP 一次性代码或 U2F 密钥。（如果需要，它还可以提供 reCAPTCHA。）

    • 通常，这也意味着您输入的密码仅在网络浏览器中可见 - 邮件应用程序实际上看不到它。

      如今，Google 尤其积极地阻止身份验证页面在“嵌入式​​”浏览器中加载，因为这可能会向主机程序泄露密码。（旧版 GNOME 曾经半合法地这样做，因为它们需要使用当时尚不支持 OAuth2 的某些 Google API。）

    • 使用网站还可以使 UI 与实际的基于 Web 的服务更加一致，并且比发明新的自定义多步骤身份验证方法在应用程序中实现得更简单。

      （与 SSH 相比，它确实具有“KeyboardInteractive”身份验证方法，可以显示带有自定义文本的多个提示 - 对于基本密码+OTP 或密钥对+OTP 来说可以正常工作，但在 2FA 方面总体上相当笨拙。许多公司实际上最终实施了使用短期 SSH 密钥对的系统，其方式与 OAuth2 令牌或 Kerberos 票证极为相似 - 您通过公司 SSO 网站进行身份验证以获取当天的 SSH 密钥。）

  • 颁发给您的邮件客户端的令牌只能访问特定服务（范围），在本例中为 IMAP 和 SMTP - 例如，它不能用于访问您的 Drive 文件或 YouTube 历史记录。

    • 虽然这在服务提供商方面可能会被滥用（例如，Google 要求对拥有超过 100 名用户并想要访问邮件相关范围的 OAuth2 应用进行昂贵的“验证”）。

    • 手动生成的“应用密码”可以也仅限于特定的服务，但很少有人会有效地使用这个功能——例如，使用 GitHub 访问令牌可以实现这一点，但需要花费太多的脑力来确定（通常通过反复试验）哪个应用程序需要哪些范围，因此在启用所有可能的范围的情况下会生成许多令牌……

对于服务提供商来说，还可以获得一些“纵深防御”优势：

  • 实际服务永远不会收到您的实际密码（甚至不会收到刷新令牌 - 只有短期访问令牌），因此即使一项服务受到损害，它也无法收集访问其他服务的凭据（“横向移动”？）。

    • 这与 Active Directory 中的 Kerberos 票证或企业 SSO 系统中的 SAML 断言的使用非常相似。

      在所有这样的系统中，并非所有服务都需要访问用户数据库（并且所有服务都是有价值的目标），而只有 KDC 或 IdP 处于特权地位。

答案2

我至少可以看到一些可能的积极因素。

  1. 它减少了密码重复使用的机会。输入密码的地方越多，发生严重泄漏的可能性就越大，而且如果您重复使用密码，其他网站也会面临风险。
  2. 它提供了一个中央授权，能够一次性快速撤销对大量网站的访问权限。由于 Google 只为网站提供“访问令牌”，因此所有网站都可以是唯一的，并且可以单独或一次性撤销。
  3. 它隐藏了网站处理密码更改和安全存储密码的需要。如果他们从未收到密码，那么他们就无法以明文形式存储密码，有些网站曾经这样做过，或者可能仍然这样做。
    他们应该仍可安全地处理令牌，但在发生违规时，这是一个更简单的过程。通知 OAuth 提供商违规，他们会撤销您的令牌，直到您在下次用户身份验证时获得新的令牌。

它确实依赖于您的 OAuth 提供商的安全性，但在一个地方重置密码仍然比在 50 或 500 个站点上重置密码容易得多。

相关内容