許多在線服務允許（有時甚至要求）您使用一次性代碼設定雙因素身份驗證 (2FA)。Google Authenticator 是生成此類代碼的最著名和使用最廣泛的身份驗證器應用程式。幾乎所有服務都與它兼容，有些服務甚至會在您設定 2FA 時提供指向該應用程式的鏈接。但 Google Authenticator 是唯一的選擇嗎，還是您應該嘗試一下眾多替代方案中的一種——例如 Microsoft Authenticator 或 Twilio Authy？

由於存在這些替代方案並且顯然擁有用戶群，您可能會認為它們可以完全替代 Google Authenticator。但是，如果有的話，陷阱是什麼？對於那些沒有時間讀到最後的人，答案馬上就來了：別擔心，Google Authenticator 不僅可以更換。但是，如果您對是什麼、為什麼以及如何感到好奇，請繼續閱讀……

 

身份驗證器的工作原理

讓我們從身份驗證器應用程式的一般工作方式開始。在開放認證倡議 (OATH) 的保護下，已經創建了幾個用於強認證的開放標準。身份驗證器應用程式基於這些標準（以及其他一些東西，但不是本文的主題）。

 

OATH HOTP

早在 2005 年，就出現了OATH HOTP（基於散列的一次性密碼）身份驗證標準。這奠定了使用在客戶端和服務器端同步生成的一次性代碼進行身份驗證的基礎。

這個想法是您正在使用的應用程式和服務都記住相同的密鑰。接下來，應用密碼算法以根據該密鑰和計數器值生成唯一代碼。計數器本質上是一個數字，每次生成新的一次性代碼時都會遞增。計算這個代碼的數據在兩邊是相同的，所以如果一切按計劃進行，兩個代碼將是相同的。剩下的就是比較它們：如果您輸入的代碼與服務器生成的代碼匹配，則身份驗證成功。

在生成會話的每個請求之後，計數器值都會發生變化，因此代碼是一次性且唯一的。使用一種算法排除執行反向計算並從該代碼中提取密鑰。因此，即使有人截獲了一次性代碼，他們也無法計算出密鑰、複製驗證器並生成自己的新代碼。

HOTP 有兩個主要問題。首先，計數器值很容易不同步。例如，如果您請求驗證器生成代碼但不使用它，則客戶端驗證器會更改計數器值，而在服務端它保持不變。結果，生成的代碼不再匹配。其次，代碼在計數器值發生變化之前一直有效——如果攻擊者以某種方式設法分散受害者的注意力，則可能會給攻擊者時間使用截獲的代碼。

 

OATH TOTP

2011 年，一項新標準公佈——OATH TOTP（基於時間的一次性密碼），它使用當前時間作為計數器。原理是一樣的：使用雙方都知道的秘鑰，用相同的密碼算法計算出一次性密碼。並且由於計數器是基於Unix 時間的，因此無論是否使用，代碼都會定期自動更改。

任何联網設備現在都知道準確時間，因此無需擔心一次性代碼不同步。而且由於代碼更改的時間間隔設定得相當短（默認為 30 秒），如果一次性代碼被攔截，攻擊者將沒有太多時間使用它。

 

認證器的基本原理

身份驗證器應用程式使用這兩個標準。TOTP 當然更常見，只是因為它在各個方面都更好，但在一些史前實現中仍然可以找到 HOTP。

創建身份驗證器時，客戶端和服務器必須設定通用標準並共享密鑰——這是身份驗證器應用運行所需的絕對最低要求。還可以設定其他參數來創建令牌。應用程式和服務如何達成一致？在大多數情況下，通過二維碼。這引出了下一個問題：這些代碼是如何工作的？

 

驗證碼二維碼內容

據我所知，這不屬於OATH制定的標準，而是自願遵守Google Authenticator設定的格式。但無論哪種方式，基於應用程式的身份驗證系統都傾向於使用二維碼，其中對包含所有必要信息的鏈接（嚴格來說，統一資源標識符或 URI ）進行了編碼。下面是它的外觀示例：

otpauth://totp/Google:[email protected]?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7&issuer=Google&algorithm=SHA1&digits=6&period=30

可以看到，二維碼中傳遞了一大堆參數，說明如下：

• URI 的目的——創建身份驗證令牌（這就是開頭的 otpauth 的用途）
• 驗證器標準，HOTP 或 TOTP；在這種情況下，TOTP
• 要在應用程式內顯示的令牌標籤——在我們的示例中，Google
• 用戶名——在本例中為 [email protected]
• 生成代碼的密鑰（Base32格式）——最重要的部分，一長串隨機字符
• 創建 URI 的服務的名稱——在我們的示例中，還是 Google
• 用於生成代碼的算法——在本例中為SHA1
• 生成代碼的長度——通常是六個字符，如此處所示，但其他變體也是可以接受的
• 代碼過期的時間段——通常為 30 秒，但可以設定其他時間間隔。

相應的二維碼如下所示：

事實上，正如我們上面提到的，這些參數中有很多是可以省略的。令牌標籤和用戶名可以是任意的，而服務的名稱根本不需要——這些信息對代碼生成沒有影響，主要是為了方便。其他一些參數也不是強制性的。身份驗證器使用默認代碼生成算法 (SHA1) 並生成具有 30 秒更新周期的六位代碼，除非在 URI 中以其他方式編碼。

本質上，服務和驗證器只需要設定標準（HOTP 或 TOTP）並共享密鑰。因此，以下 URI 和 QR 代碼將產生與前一對在功能方面完全相同的身份驗證令牌：

otpauth://totp/Whenever:Wherever?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7

最重要的是，大多數使用應用程式生成的代碼進行身份驗證的服務都使用此類二維碼進行操作。反過來，任何身份驗證器應用程式都支持讀取此類 QR 碼並將其轉換為身份驗證令牌，進而生成一次性代碼。因此，除了 Google Authenticator，您還可以選擇數十種您喜歡的替代方案中的任何一種。

一些例外：與常規身份驗證器不兼容的服務

出於某種我無法理解的原因，並非 IT 行業中的每個人都遵循上述標準：有些人更願意提出自己的標準。以下是一些公司的服務和程式與第三方身份驗證器應用程式（包括 Google Authenticator）不兼容的情況。

• 蘋果。庫比蒂諾的人有他們自己的 2FA 系統，它根本不使用第三方應用程式。相反，一次性代碼由操作系統同時在所有鏈接到 Apple ID 的設備上生成。他們就是這樣滾動的！
• Valve和暴雪。為了確保 Steam 和 Battle.net 的安全性，開發人員提供了他們自己創建的 2FA：Steam Guard（內置於適用於 Android 和 iOS 的 Steam 應用程式中）和 Battle.net Authenticator。據我所知，只有一個第三方驗證器應用程式支持這些系統：WinAuth。
• 微軟。對於 Microsoft 帳戶身份驗證，您必須安裝 Microsoft Authenticator。從好的方面來說，無需輸入任何代碼：只需點擊應用程式中的按鈕確認登錄即可。作為獎勵，Microsoft Authenticator 還生成標準身份驗證令牌，這使其成為 Google Authenticator 的可靠替代品。順便說一句，您不需要 Microsoft 帳戶即可使用它。
• Adobe。圖形軟件開發商提供了自己的 2FA 應用程式——Adobe 帳戶訪問——其工作原理與 Microsoft Authenticator 類似：通過點擊按鈕驗證登錄 Adob​​e 帳戶，而不是發送代碼。理論上，該應用程式還支持創建令牌以在第三方服務中進行身份驗證。但是，要獲得 Adob​​e 帳戶訪問權限，您必須首先將應用程式鏈接到您的 Adob​​e 帳戶，根據App Store和Google Play 的評論，不建議這樣做。

那麼，我必須使用GOOGLE身份驗證器嗎？

不必要。所有與 Google Authenticator 配合使用的服務都可以讓您使用任何替代應用程式設定雙因素身份驗證。更重要的是，其中許多與GOOGLE的創造相比具有顯著優勢。

順便說一下，我們有一篇關於每個流行操作系統（Android、iOS、Windows 和 macOS）最有趣的身份驗證器的帖子。最後，如果您完整閱讀了本文，那麼有些事情告訴我們您可能對andOTP感興趣（如果您使用的是 Android），以及OTP auth（如果您使用的是 iOS）。