One-Time-Password
為什麼不只為一次性密碼 (OTP) 生成隨機字元串？
http://en.wikipedia.org/wiki/One-time_password#How_OTPs_are_generated_and_distributed
為什麼有這麼多生成 OTP 的方法，為什麼不只使用隨機字元串？
僅使用隨機字元串是簡單且通常合理的解決方案。但是，如果您擁有大量客戶群，它可能會變得過於昂貴，因為所有這些隨機字元串都需要儲存。
但簡而言之，這些更複雜的方案主要是為了減少儲存需求和所需的熵量。注意：我在前兩個回复的基礎上部分建構了這個回复。
減少所需的熵和儲存要求
僅生成隨機字元串意味著需要生成和儲存比許多經過深思熟慮的 OTP 機制更多的隨機位。例如，S/KEY 只需要生成和儲存一個值，即使可以有例如一百個密碼，從而將儲存成本降低到（理論上）多達百分之一的隨機字元串。因為需要較少的隨機位（熵），所以 OTP 機制更容易測試和驗證。
（注意：為了順利處理轉換和過期，通常需要儲存多個值。）。
我在某種程度上同意 md_1976，但是，我不同意儲存在伺服器上的資訊量。基於時間的 OTP 方案通常仍然需要一些關於使用者帳戶的資訊，例如使用者身份驗證設備（硬體設備）的序列號。如果有基於時間的 OTP 的軟體實現，伺服器可能需要知道使用者設備的公鑰，或者伺服器和設備可能需要共享密鑰。基於時間的 OTP 方案的一個可能問題是它們往往需要特殊的客戶端軟體或硬體。另一方面，傳統的 OTP 方案甚至可以通過例如信件和電話網路工作。
在具有客戶端硬體設備的基於時間的方案中，每個帳戶要儲存的典型資訊可以是設備的序列號和/或其他辨識碼。
儲存值的大小
出於比較成本的目的。（未考慮可能的其他值，例如帳戶 ID 或時間戳。）
- 原始 S/KEY (RFC 1760) - 這是基於 MD4 雜湊函式，被認為是損壞的。不建議使用。
- OTP (RFC 2289)，基於 MD4/MD5 或 SHA1。每個 OTP 密鑰需要 64 位儲存。
- HOTP (RFC 4226)：共享密鑰為 128 位或更多（推薦 160 位）。
- TOTP (RFC 6238)：使用與 HOTP 相同大小的共享密鑰。