我正在编写SMTP服务器并已实施CRAM-MD5身份验证。要计算质询响应字符串，我显然需要在服务器上存储明文密码。
这背后的原因是什么？这个身份验证机制似乎存在难以置信的缺陷，只要：
对我来说，如果总是需要TLS，CRAM-MD5确实看起来不太安全PLAIN / LOGIN认证。
答案 0 :(得分：3)
是的，由于密码重用，存储密码，即使是可逆加密，也比某种盐渍哈希更糟糕。可以说，从明文密码生成某些东西（如PBKDF2或常规盐渍哈希）然后在两侧使用它会更安全一些。但是，它要求客户端了解服务器的散列方案，包括用于此帐户的salt。无论你如何切片，都会给你留下与CRAM-MD5不相容的东西，而且不一定好多了。
我建议完全忘记CRAM-MD5因为这个问题和其他问题。特别是，它使用MD5，它被认为是破碎的，并且有various known weaknesses。最大的问题是连接没有加密，所以任何人都可以嗅出实际的内容。
更好的答案是使用TLS。
答案 1 :(得分：2)
您不需要在服务器上存储明文密码，您只需存储公式的MD5上下文，它是专门为此设计的：
HMAC(K, M) -> H(K1, H(K2, M))
请注意，K1和K2始终是哈希的第一个输入，并且总是64字节长，无论密钥/密码的大小，还要注意此算法与其他哈希（SHA1，SHA256，...）兼容。 ..）
来自RFC6151（2011年3月）
MD5不再适用于需要抗冲击性的地方，如数字签名。以其他方式停止使用MD5并不紧急，例如HMAC-MD5
来自RFC2195（1997年9月）
使用[KEYED-MD5]中描述的技术进行中间结果的预计算可以避免在服务器系统上明确明确存储共享密钥，而是存储称为“上下文”的中间结果< / p>
答案 2 :(得分：0)
当然，如果你想保留一个不可逆密码作为CRAM-MD5的密钥，你可以修改CRAM-MD5以使用PBKDF功能的输出，如PBKDF2。你需要两边的盐。
然而，这不是很有用，因为攻击者可以直接使用PBKDF2的输出作为CRAM-MD5的输入。因此，唯一的优点是用户的密码不会直接暴露（密码经常被重用）。即使使用普通登录，强烈建议在服务器上使用PBKDF2，因为它可以减轻受损数据库的影响。
当然，将CRAM-MD5与KDF一起使用会使其成为专有协议，因此的互操作性将受到影响。
但是，由于检索密码意味着破坏TLS，PLAIN / LOGIN应该适用于大多数用例。
请注意，我不是CRAM-MD5的专家，我只是快速阅读维基百科上的协议。