你好！另一個晚上，在回家的路上，我決定檢查一下郵箱。我指的不是我的電子郵件收件箱，而是郵差放置實際信件的老式實際盒子。令我驚訝的是，我在那裡發(fā)現(xiàn)了一個信封，裡面裝著一些東西！當我打開它時，我花了一些時間希望這是來自霍格華茲的遲來了幾十年的信。但當我注意到這是一封來自銀行的無聊的「成人」信時，我不得不回到現(xiàn)實。我瀏覽了一下文字，意識到我的「酷孩子純數(shù)字」銀行已被當?shù)厥袌錾献畲蟮耐婕沂召?。作為新開始的象徵，他們在信封上添加了以下內(nèi)容：

以及如何使用它的說明。

如果你像我一樣，從來沒有遇到過這樣的技術(shù)創(chuàng)新，讓我分享一下我從信中學到的東西：新所有者決定執(zhí)行他們公司的安全策略，這意味著所有用戶從現(xiàn)在開始，帳戶將啟用MFA（順便說一句，這是值得稱讚的）。您在上面看到的裝置會產(chǎn)生 6 位數(shù)字長的一次性令牌，在登入您的銀行帳戶時用作第二因素?；旧?，與 Authy、Google Authenticator 或 2FAS 等應(yīng)用程式的工作方式相同，但採用物理形狀。

所以，我嘗試了一下，登入過程很順利：設(shè)備向我顯示了一個 6 位元代碼，我在我的銀行應(yīng)用程式中輸入了它，這讓我進入了。萬歲！但後來我突然意識到：這東西是如何運作的？它無法以某種方式連接到互聯(lián)網(wǎng)，但它設(shè)法產(chǎn)生我的銀行伺服器接受的正確代碼。嗯...裡面有SIM卡或類似的東西嗎？沒辦法！

意識到我的生活將永遠不一樣，我開始想知道我上面提到的應(yīng)用程式（Authy 和朋友）？我內(nèi)心的研究員被喚醒了，所以我將手機切換到飛行模式，令我大吃一驚的是，我意識到它們在離線狀態(tài)下工作得非常好：它們不斷生成被應(yīng)用程式伺服器接受的程式碼。有趣！

不確定你的看法，但我一直認為一次性代幣流是理所當然的，並且從未真正認真考慮過它（特別是因為現(xiàn)在我的手機很少沒有互聯(lián)網(wǎng)，除非我正在做一些戶外探險），所以這是我驚訝的根本原因。否則，從安全的角度來看，以這種方式工作是完全有意義的，因為生成過程純粹是本地的，因此對於外部參與者來說是安全的。但它是如何運作的呢？

嗯，像 Google 或 ChatGPT 這樣的現(xiàn)代技術(shù)可以讓您輕鬆找到答案。但這個技術(shù)問題對我來說似乎很有趣，所以我決定先嘗試一下並自己解決。

要求

讓我們從我們擁有的開始：

• 可產(chǎn)生 6 位元代碼的離線設(shè)備
• 伺服器接受這些程式碼，驗證它們，如果正確則發(fā)出綠色訊號

伺服器驗證部分提示伺服器必須能夠產(chǎn)生與離線設(shè)備相同的程式碼來比較它們。嗯..這會很有幫助。

對我的新「玩具」的進一步觀察帶來了更多發(fā)現(xiàn)：

• 如果我將其關(guān)閉然後再關(guān)閉，通常我可以看到與之前相同的程式碼
• 然而，偶爾，它會改變

我能想到的唯一邏輯解釋是這些程式碼有一定的生命週期。我想講述一個我試圖以“1-2-3-...-N”方式計算它的持續(xù)時間的故事，但這不會是真的：我從像這樣的應(yīng)用程式中得到了一個很大的提示Authy and Co，我在那裡看到了30 秒的TTL。很好的發(fā)現(xiàn)，讓我們將其添加到已知事實列表中。

讓我們總結(jié)一下到目前為止我們的要求：

• 以 6 位數(shù)字格式產(chǎn)生可預測（而非隨機）的代碼
• 生成邏輯應(yīng)該是可重現(xiàn)的，這樣無論平臺如何，都可以得到相同的結(jié)果
• 程式碼生命週期為 30 秒，這表示在這段時間內(nèi)產(chǎn)生演算法會產(chǎn)生相同的值

大問題

好吧，但主要問題仍然沒有得到解答：離線應(yīng)用程式如何產(chǎn)生與其他應(yīng)用程式中的值相符的值？他們有什麼共同點？

如果您喜歡《魔戒》宇宙，您可能還記得比爾博如何與咕嚕玩謎語遊戲，並解決了這個問題：

這個萬物吞噬之物：
鳥、獸、樹、花；
啃鐵咬鋼；
將堅硬的石頭磨成粉；
殺死國王，摧毀城鎮(zhèn)，
並擊敗高山。

劇透警告，但巴金斯先生很幸運，意外地得出了正確答案 - “時間！”。不管你相信與否，這也正是我們謎題的答案：任何 2 個（或更多）應(yīng)用程式都可以存取同一時間，只要它們內(nèi)部有嵌入式時鐘。如今，後者已不再是問題，而且所討論的設(shè)備足夠大，可以容納它。環(huán)顧四周，你的手錶、手機、電視、烤箱和牆上的時鐘上的時間很可能是相同的。我們在這裡很感興趣，似乎我們已經(jīng)找到了 OTP（一次性密碼）計算的基礎(chǔ)！

挑戰(zhàn)

依賴時間有其自身的一系列挑戰(zhàn)：

• 時區(qū) - 使用哪一個？
• 時鐘往往會不同步，這對分散式系統(tǒng)來說是一個巨大的挑戰(zhàn)

讓我們一一解決：

• 時區(qū)：這裡最簡單的解決方案是確保所有設(shè)備都依賴同一區(qū)域，並且 UTC 可以是一個很好的與位置無關(guān)的候選
• 至於時鐘不同步：實際上，我們甚至可能不需要解決它，而是接受不可避免的事情，只要漂移在一兩秒之內(nèi)，考慮到 30 秒的 TTL，這可能是可以容忍的。設(shè)備的硬體生產(chǎn)商應(yīng)該能夠預測何時會實現(xiàn)這種漂移，因此設(shè)備將使用它作為其到期日期，而銀行將簡單地用新的替換它們，或者將有辦法連接它們到網(wǎng)路來校準時鐘。至少，這是我的想法。

執(zhí)行

好的，這件事已經(jīng)解決了，所以讓我們嘗試以時間為基礎(chǔ)來實現(xiàn)我們演算法的第一個版本。由於我們對 6 位數(shù)字結(jié)果感興趣，因此依賴時間戳而不是人類可讀的日期聽起來是一個明智的選擇。讓我們從這裡開始：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

根據(jù) Go 文檔，.Unix() 返回

自 UTC 1970 年 1 月 1 日以來經(jīng)過的秒數(shù)。

這是終端列印的內(nèi)容：

Current timestamp:  1733691162

這是一個好的開始，但是如果我們重新運行該程式碼，時間戳值將會改變，而我們希望保持它穩(wěn)定 30 秒。好吧，小菜一碟，我們將其除以 30 並使用該值作為基數(shù)：

// gets current timestamp
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds
base := current / 30
fmt.Println("Base: ", base)

讓我們運行它：

Current timestamp:  1733691545
Base:  57789718

再說一次：

Current timestamp:  1733691552
Base:  57789718

基礎(chǔ)值維持不變。讓我們稍等一下，然後再次運行：

Current timestamp:  1733691571
Base:  57789719

隨著 30 秒視窗的過去，基礎(chǔ)值已更改 - 幹得好！

如果「除以30」的邏輯沒有意義，讓我用一個簡單的例子來解釋：

• 想像一下我們的時間戳回 1
• 如果我們將 1 除以 30，結(jié)果將為 0，就像當我們使用嚴格類型程式語言時，整數(shù)除以整數(shù)會傳回另一個整數(shù)，該整數(shù)與浮點部分無關(guān)
• 這意味著在接下來的 30 秒內(nèi)，當時間戳介於 0 到 29 之間時，我們將得到 0
• 一旦時間戳達到30，除法的結(jié)果就是1，直到60（變成2），依此類推

我希望它現(xiàn)在更有意義。

但是，還沒有滿足所有要求，因為我們需要 6 位數(shù)字的結(jié)果，而當前基數(shù)截至今天是 8 位數(shù)字，但在未來的某個時間點可能會達到 9 位數(shù)字點，依此類推。好吧，讓我們使用另一個簡單的數(shù)學技巧：將基數(shù)除以1 000 000，並得到餘數(shù)，餘數(shù)始終為6 位數(shù)字，因為提醒可以是0 到999 999 之間的任何數(shù)字，但不能更大：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

fmt.Sprintf(" d", code) 部分會附加前導零，以防我們的程式碼值少於 6 位元。例如，1234 將轉(zhuǎn)換為 001234。
這篇文章的完整程式碼可以在這裡找到。

讓我們執(zhí)行此程式碼：

Current timestamp:  1733691162

好的，我們得到了 6 位元程式碼，萬歲！但這裡感覺有些不對勁，不是嗎？如果我給您這個程式碼，並且您將與我同時運行它，您將獲得與我相同的程式碼。這並不意味著它是一個安全的一次性密碼，對吧？新的要求來了：

• 不同使用者的結(jié)果應(yīng)該不同

當然，如果我們的用戶超過 100 萬，一些衝突是不可避免的，因為這是每 6 位數(shù)字的最大可能唯一值。但這些都是罕見的，技術(shù)上不可避免的碰撞，而不是像我們現(xiàn)在這樣的演算法設(shè)計缺陷。

我認為任何聰明的數(shù)學技巧本身都不會幫助我們：如果我們需要每個使用者單獨的結(jié)果，我們需要一個特定於使用者的狀態(tài)來實現(xiàn)它。作為工程師，同時也是許多服務(wù)的用戶，我們知道要授予對其 API 的存取權(quán)限，服務(wù)依賴私鑰，而私鑰對於每個用戶來說都是唯一的。讓我們?yōu)槲覀兊挠美胍粋€私鑰，以區(qū)分用戶。

私鑰

產(chǎn)生 1 000 000 到 999 999 999 之間整數(shù)的私鑰的簡單邏輯：

// gets current timestamp
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds
base := current / 30
fmt.Println("Base: ", base)

我們使用 pkDb 映射作為防止私鑰之間重複的方法，如果檢測到重複，我們將再次運行生成邏輯，直到獲得唯一的結(jié)果。

讓我們執(zhí)行此程式碼來取得私鑰範例：

Current timestamp:  1733691545
Base:  57789718

讓我們在程式碼產(chǎn)生邏輯中使用此私鑰，以確保每個私鑰得到不同的結(jié)果。由於我們的私鑰是整數(shù)類型，所以我們能做的最簡單的事情就是將其添加到基值上，並保持其餘演算法不變：

Current timestamp:  1733691552
Base:  57789718

讓我們確保它對於不同的私鑰產(chǎn)生不同的結(jié)果：

Current timestamp:  1733691571
Base:  57789719

結(jié)果看起來符合我們的期望：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds:
base := current / 30
fmt.Println("Base: ", base)

// makes sure it has only 6 digits:
code := base % 1_000_000

// adds leading zeros if necessary:
formattedCode := fmt.Sprintf("%06d", code)
fmt.Println("Code: ", formattedCode)

魅力十足！這意味著私鑰應(yīng)該先註入生成程式碼的裝置中，然後再發(fā)送給像我這樣的用戶：這對銀行來說根本不應(yīng)該是問題。

我們現(xiàn)在完成了嗎？好吧，前提是我們對我們使用的人工場景感到滿意。如果您曾經(jīng)為您擁有帳戶的任何服務(wù)/網(wǎng)站啟用過 MFA，您可能會注意到網(wǎng)路資源要求您使用您選擇的第二因素應(yīng)用程式（Authy、Google Authenticator、2FAS 等）掃描 QR 碼。 ），它將把密碼輸入到您的應(yīng)用程式中，並從那時起開始產(chǎn)生 6 位數(shù)字的代碼?；蛘?，也可以手動輸入代碼。

我提出這個是為了一睹業(yè)界使用的真實私鑰的格式。它們通常是 16-32 個字元長的 Base32 編碼字串，如下所示：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

如您所見，這與我們使用的整數(shù)私鑰有很大不同，如果我們要切換到這種格式，我們演算法的當前實作將無法運作。我們?nèi)绾握{(diào)整我們的邏輯？

私鑰作為字串

讓我們從一個簡單的方法開始：我們的程式碼將無法編譯，因為這一行：

Current timestamp:  1733691162

因為 pk 從現(xiàn)在開始是字串型。那我們?yōu)槭颤N不把它轉(zhuǎn)換成整數(shù)呢？雖然有更優(yōu)雅和更有效率的方法可以做到這一點，但這是我想到的最簡單的方法：

// gets current timestamp
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds
base := current / 30
fmt.Println("Base: ", base)

這很大程度上是受到 String 資料類型的 Java hashCode() 實作的啟發(fā)，這使得它足以滿足我們的場景。

調(diào)整後的邏輯如下：

Current timestamp:  1733691545
Base:  57789718

這是終端輸出：

Current timestamp:  1733691552
Base:  57789718

很好，有 6 位元程式碼，幹得好。讓我們等待到達下一個時間窗口並再次運行它：

Current timestamp:  1733691571
Base:  57789719

嗯...它可以工作，但是程式碼基本上是前一個值的增量，這不好，因為這樣OTP 是可預測的，並且擁有它的值並知道它屬於什麼時間，這是非常好的無需知道私鑰即可開始產(chǎn)生相同的值。這是此駭客攻擊的簡單偽代碼：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds:
base := current / 30
fmt.Println("Base: ", base)

// makes sure it has only 6 digits:
code := base % 1_000_000

// adds leading zeros if necessary:
formattedCode := fmt.Sprintf("%06d", code)
fmt.Println("Code: ", formattedCode)

其中 keepWithinSixDigits 將確保在 999 999 之後下一個值是 000 000 等等，以將該值保持在 6 位數(shù)字的限制範圍內(nèi)。

如您所見，這是一個嚴重的安全漏洞。為什麼會發(fā)生這種情況？如果我們看一下基本計算邏輯，我們會發(fā)現(xiàn)它依賴兩個因素：

• 當前時間戳記除以 30
• 私鑰的雜湊值

雜湊對於相同的鍵產(chǎn)生相同的值，因此它的值是恆定的。至於當前的 / 30 ，它在 30 秒內(nèi)具有相同的值，但是一旦視窗過去，下一個值將是前一個值的增量。然後 base % 1_000_000 的行為就像我們看到的那樣。我們之前的實作（使用私鑰作為整數(shù)）也有同樣的漏洞，但我們沒有註意到這一點 - 缺乏測試。

我們需要將 current / 30 轉(zhuǎn)換成某些東西，使其值的變化更加明顯。

分佈式 OTP 值

有多種方法可以實現(xiàn)這一點，並且存在一些很酷的數(shù)學技巧，但出於教育目的，讓我們優(yōu)先考慮我們將採用的解決方案的可讀性：讓我們將current / 30 提取到一個單獨的變數(shù)基數(shù)中並包含進入雜湊計算邏輯：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

這樣，即使底數(shù)每 30 秒變化 1，但在 hash() 函數(shù)邏輯中使用後，diff 的權(quán)重會因為一系列乘法的執(zhí)行而增加。

這是更新後的程式碼範例：

Current timestamp:  1733691162

讓我們運行它：

// gets current timestamp
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds
base := current / 30
fmt.Println("Base: ", base)

繁榮！我們怎麼會在這裡得到負值呢？好吧，看起來我們已經(jīng)超出了 int64 範圍，因此它將值限制為負數(shù)並重新開始 - 我的 Java 同事透過 hashCode() 行為對此很熟悉。 解決方法很簡單：讓我們從結(jié)果中取絕對值，這樣減號就被忽略：

Current timestamp:  1733691545
Base:  57789718

這是修復後的完整程式碼範例：

Current timestamp:  1733691552
Base:  57789718

讓我們運行它：

Current timestamp:  1733691571
Base:  57789719

讓我們再次運行它以確保 OTP 值現(xiàn)在已分發(fā)：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds:
base := current / 30
fmt.Println("Base: ", base)

// makes sure it has only 6 digits:
code := base % 1_000_000

// adds leading zeros if necessary:
formattedCode := fmt.Sprintf("%06d", code)
fmt.Println("Code: ", formattedCode)

很好，終於有一個不錯的解決方案了！

實際上，那是我停止手動實施過程的那一刻，因為我享受到了樂趣並學到了新東西。然而，這既不是最好的解決方案，也不是我願意接受的解決方案。除此之外，它還有一個很大的缺陷：如您所見，由於雜湊邏輯和時間戳記值，我們的邏輯總是處理大數(shù)字，這意味著我們不太可能產(chǎn)生以1 或1 開頭的結(jié)果。更多零：例如 012345 、 001234 等，即使它們完全有效。因此，我們還缺少 100 000 個可能的值，這比演算法的可能結(jié)果數(shù)量少了 10% - 這樣碰撞的可能性會更高。不酷！

從這裡到哪裡去

我不會深入探討實際應(yīng)用程式中使用的實現(xiàn)，但對於那些好奇的人，我將分享兩個值得一看的 RFC：

• HOTP：一種基於 HMAC 的一次性密碼演算法
• TOTP：基於時間的一次性密碼演算法

這是偽代碼實現(xiàn)，它將根據(jù)上述 RFC 以預期方式工作：

Current timestamp:  1733692423
Base:  57789747
Code:  789747

如您所見，我們已經(jīng)非常接近了，但原始演算法使用更高級的雜湊（本例中為 HMAC-SHA1），並執(zhí)行一些位元運算來標準化輸出。

安全考慮：重複使用而不是自己構(gòu)建

但是，在我們結(jié)束之前我還想講一件事：安全性。我強烈建議您不要自行實作產(chǎn)生 OTP 的邏輯，因為有許多函式庫已經(jīng)為我們完成了這項工作。犯錯的空間是巨大的，而且離不良行為者發(fā)現(xiàn)和利用的漏洞只有很短的距離。

即使您的生成邏輯正確並通過測試覆蓋它，也可能會出現(xiàn)其他問題。例如，您認為暴力破解 6 位數(shù)代碼需要花費多少時間？讓我們來實驗一下：

// gets current timestamp:
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

讓我們執(zhí)行此程式碼：

Current timestamp:  1733691162

再一次：

// gets current timestamp
current := time.Now().Unix()
fmt.Println("Current timestamp: ", current)

// gets a number that is stable within 30 seconds
base := current / 30
fmt.Println("Base: ", base)

如您所見，透過簡單的暴力 for 迴圈猜測程式碼大約需要 70 毫秒。這比 OTP 的壽命快 400 倍！使用 OTP 機制的應(yīng)用程式/網(wǎng)站的伺服器需要透過例如在 3 次失敗嘗試後的接下來 5 或 10 秒內(nèi)不接受新程式碼來防止這種情況。這樣，攻擊者在 30 秒的視窗內(nèi)只能相應(yīng)地獲得 18 或 9 次嘗試，這對於 100 萬個可能值的池來說是不夠的。

還有其他類似的事情很容易被忽略。所以，讓我再說一次：不要從頭開始建立它，而是依賴現(xiàn)有的解決方案。

無論如何，我希望你今天學到了一些新東西，從現(xiàn)在開始 OTP 邏輯對你來說不再是一個謎。此外，如果在生活中的某個時刻，您需要使用可重現(xiàn)的演算法讓離線設(shè)備產(chǎn)生一些值，那麼您很清楚從哪裡開始。

感謝您花時間閱讀這篇文章，祝您玩得開心！ =)

P.S.我發(fā)布新帖子後會收到一封電子郵件 - 在此訂閱

P.P.S.和其他酷孩子一樣，我最近創(chuàng)建了一個 Bluesky 帳戶，所以請幫助我讓我的 Feed 變得更有趣 =)

以上是揭秘 OTP：離線產(chǎn)生代幣背後的邏輯的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！