☰

oAuth 如何更安全？

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

許多服務（例如 Google 的 IMAP 郵件）已從使用者 ID/密碼驗證轉向使用 oAuth。

除了 oAuth 是由一家實力雄厚、擁有更多資源可監控的大公司提供的服務之外，oAuth 還如何更安全？

答案1

其技術優勢為：

  • 由於 OAuth 的「初始身份驗證」部分是透過網站完成的，因此它可以更輕鬆地要求其他身份驗證因素而不僅僅是密碼。例如，它可能會要求 TOTP 一次性代碼或 U2F 金鑰。 （如果需要的話，它也可以有 reCAPTCHA。）

    • 一般來說，這也意味著您輸入的密碼僅對網頁瀏覽器可見 - 郵件應用程式實際上永遠看不到它。

      如今，Google在阻止身份驗證頁面載入到「嵌入式」瀏覽器中尤其積極，這可能會向主機程式洩露密碼。 （舊的 GNOME 版本曾經半合法地執行此操作，因為它們需要使用當時尚不支援 OAuth2 的某些 Google API。）

    • 使用網站還可以使 UI 與實際的基於 Web 的服務更加一致，並且比發明新的自訂多步驟身份驗證方法更容易在應用程式中實現。

      （與SSH 相比，SSH 確實有一個“KeyboardInteractive”身份驗證方法，可以顯示多個帶有自定義文本的提示- 對於基本密碼+ OTP 或密鑰對+ OTP 來說效果很好，但總體來說在2FA 方面相當笨拙。 ）

  • 發給您的郵件用戶端的令牌只能存取特定服務（範圍），在本例中為 IMAP 和 SMTP – 例如，它不能用於存取您的雲端硬碟檔案或 YouTube 歷史記錄。

    • 儘管這在服務提供者方面可能會被濫用（例如，Google 需要對擁有超過 100 個使用者並希望存取郵件相關範圍的 OAuth2 應用程式進行昂貴的「驗證」）。

    • 手動產生的“應用程式密碼”可以也僅限於特定服務，但很少有人會有效地使用該功能 - 例如，這可以透過 GitHub 存取權杖實現，但需要花費太多精力來確定（通常透過反覆試驗）哪些應用程式需要哪些範圍，因此啟用每個可能的範圍後將產生許多令牌...

對於服務提供者來說，還有一些「縱深防禦」優勢：

  • 實際服務永遠不會收到您的實際密碼（甚至也不會收到刷新令牌- 只有短期存取令牌），因此即使一項服務受到損害，它也無法收集用於存取其他服務的憑證（“橫向移動”？）。

    • 這與 Active Directory 中的 Kerberos 票證或企業 SSO 系統中的 SAML 斷言的使用非常相似。

      在所有此類系統中，並非所有服務都需要存取使用者資料庫（並且所有服務都是有價值的目標），您只剩下 KDC 或 IdP 處於特權位置。

答案2

我至少可以看到一些可能的正面因素。

  1. 它減少了密碼重複使用的機會。您輸入密碼的位置越多，嚴重洩漏的可能性就越大，如果您重複使用密碼，那麼其他網站也會面臨風險。
  2. 它提供了一個能夠一次快速撤銷對大量網站的存取的中央權限。由於 Google 僅向網站提供“訪問令牌”，因此它們都可以是唯一的，並且可以單獨或一次全部撤銷。
  3. 它隱藏了網站處理密碼更改和安全儲存密碼的需求。如果他們從未收到密碼，那麼他們就無法以明文形式儲存密碼，某些網站已經這樣做或可能仍然這樣做。
    他們應該仍然安全地處理令牌，但在發生違規的情況下，這是一個更簡單的過程。通知 OAuth 提供者違規情況，他們會撤銷您的令牌，直到您下次使用者進行身份驗證時獲得新令牌。

它確實依賴您的 OAuth 提供者的安全，但在一個地方重設密碼仍然比在 50 或 500 個網站上重設密碼要容易得多。

相關內容