Hash
在不使用 SSL 連接時，將 CRAM-MD5 用於電子郵件有哪些潛在的安全影響？
背景：我目前的伺服器提供商告訴我，將密碼以純文字形式儲存在數據庫中是沒有問題的，他說他必須這樣做，因為他們使用 CRAM-MD5 進行電子郵件身份驗證。但是有些事情告訴我，以純文字形式將密碼儲存在數據庫中可能不是這裡出現的唯一安全問題，我什至不確定 CRAM-MD5 是否仍然可以從密碼學的角度被認為是“安全的”。畢竟，我肯定不想對電子郵件流量使用不安全的東西。
無論您能給我什麼回饋——從密碼學的角度來看——關於*“在不使用 SSL 連接的情況下與電子郵件伺服器交談時使用 CRAM-MD5 進行身份驗證”*將受到高度讚賞。提前致謝。
編輯：對於資訊安全的觀點，請檢查https://security.stackexchange.com/questions/36117/how-secure-is-using-cram-md5-for-email-authentication-when-not-using-an- ssl-con
CRAM-MD5是一個展示密碼知識的協議。在電子郵件的上下文中，電子郵件客戶端有時使用它來對 POP、IMAP 或/和 SMTP 伺服器進行身份驗證。基本上，密碼在質詢-響應協議中用作HMAC-MD5的密鑰。
關於 CRAM-MD5，有一些積極的方面：
- 密碼未明文交換。
- 該協議不易被重放。
- HMAC-MD5 很強大（即使MD5作為抗碰撞雜湊被破壞）；因此**，如果密碼無法猜測，CRAM-MD5將**提供強大的保護，防止對手使用被動竊聽進行登錄。
- 就協議而言，密碼可以很長並且包含任意字元，如果至少可行的話，可以實現上述操作。
- 可以想像使用密碼的不可逆轉換，而不是密碼本身來執行協議（通過將兩個 MD5 散列中的每一個的第一輪輸出保存在 HMAC-MD5 中）；因此，使用 CRAM-MD5 的伺服器實際上不需要保持密碼清晰，也不需要任何允許直接派生密碼的方法（據報導，“將密碼以純文字形式儲存在數據庫中”的藉口可能反映了實踐，但這是錯誤的從嚴格的密碼學角度來看）。
- MD5 Rainbow Tables無法通過被動竊聽從攔截中破解密碼：挑戰打敗了它。
- 實現很簡單。
不利的一面：
- CRAM-MD5在實踐中並不能滿足其對被動竊聽者保密密碼的主要目標（例如使用WireShark），因為測試特定密碼很快（它需要一個 HMAC-MD5，通常是 4 個 MD5 輪），密碼破解者可以猜測除少數偏執的安全意識之外的任何人選擇的密碼。例如，據報導，這個野獸每秒執行 1800 億次 MD5，這可能是每秒測試 2 35個密碼，平均不到 5 分鐘即可破解強制性 XKCD 參考建議的強（44 位）變體; 弱（28 位）變體已經遠遠高於平均密碼實踐，很容易受到使用John-the-Ripper的腳本小子的攻擊。
- CRAM-MD5 向另一方驗證一方，而不是相反；在電子郵件實踐中，客戶端無法確定它連接到哪個伺服器來接收或發送電子郵件。
- 使用 CRAM-MD5 並不能保護登錄後交換數據的機密性或完整性：電子郵件可以被被動竊聽者讀取，主動攻擊者可以在現有會話中插入命令。
總結：CRAM-MD5 提供強大的保護，防止通過竊聽洩露異常強的密碼，為現實生活中的密碼提供符號保護，幾乎沒有其他安全功能。在 ISP 提供的電子郵件服務的上下文中，有些人會認為這個問題沒有實際意義：以這種方式交換的電子郵件（沒有如GPG提供的端到端安全性）在許多其他方面都是不安全的。