是否有可能在服務器上加鹽和散列HOTP/TOTP祕密？

Question

我正在構建基於TOTP/HOTP的雙因素身份驗證系統。 爲了驗證otp，服務器和otp設備都必須知道共享密鑰。

由於HOTP密碼與用戶密碼非常相似，因此我認爲應該採用類似的最佳做法。特別強烈建議不要存儲未加密的密碼，只保存密碼的哈希值。

HOTP/TOTP的RFC和Python實現似乎都沒有涵蓋這方面。

有沒有辦法使用OTP共享密鑰的單向加密，還是一個愚蠢的想法？

Answer 1

有沒有辦法使用單向加密的OTP共享密鑰......？

不是。你可以使用可逆加密機制，但可能沒有多少意義。

你只能湊在服務器上的HMAC關鍵，如果客戶端通過發送跨網絡的完整的非散列HMAC密鑰，通常是如何基於密碼的驗證工作驗證，但是這將是容易受到重放攻擊，這是正是HOTP/TOTP設計要避免的。

爲什麼我們在存儲密碼之前對密碼應用單向函數（salt + hash）......？

這實際上是一個很好的問題。

我認爲這是因爲早期版本的Unix操作系統將其所有密碼信息都存儲在'全球可讀的'/etc/passwd文件中，因此它們顯然必須以某種方式進行混淆，而salt + hash只是恰巧是他們選擇的方法。

現在，人們通常不會使自己的密碼文件如此免費，所以可以說沒有必要對它們進行散列。

但是，還有另一個理由來混淆它們，即密碼通常是由人類選擇的，所以爲了方便起見，他們通常會爲多個系統選擇相同的密碼。我懷疑HMAC密鑰也是如此，它們（希望）是使用密碼更強的機制來選擇的。

所以，主要原因時下散列密碼，與其說是增加你的系統的安全性，但降低影響您的用戶對其他系統安全的風險，應將系統已被泄露。

如果攻擊者可以從系統中讀取明文密碼，那麼對他們來說可能沒有多大用處，因爲他們也可能讀取系統中的所有其他信息。

但是，如果在另一個系統上也使用了相同的密碼，那麼您可能已經向攻擊者提供了破壞該系統的手段。

如果人們可以信任不要爲多個系統使用相同的密碼，那麼可能根本不需要對它們進行哈希處理，但我認爲假設這種情況有可能發生是有點樂觀的。:-)

Answer 2

定義：HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF - 其中K是一個密鑰，C是一個計數器。它的設計使得黑客無法獲得K和C，因爲HMAC是單向散列（不是雙向加密），因此它們具有HOTP字符串。

K & C需要保護，因爲丟失會危及整個OTP系統。話雖如此，如果在字典中找到K，並且我們知道C（例如：當前時間），我們可以生成HOTP/TOTP的整個字典並計算出K。

對HOTP/TOTP應用單向加密（即：雙重加密）雖然不會阻止其他形式的攻擊（例如：按鍵記錄）或對字典應用相同的加密，但在數學上會使其難以解碼HOTP/TOTP列表。

重複使用同一套易於記憶的密碼來處理所有事情，因此需要在數字設備上或通過互聯網傳輸時隱藏此密碼。

安全程序或協議的執行也很重要，這就像選擇一個好的密碼K但離開它趴在課桌周圍的每一個人，或服務器保持K（用於HMAC）是不被保護的私有網絡中幾層防火牆。