实施 CRAM-MD5 是个好主意吗？答案

【问题标题】：Is implementing CRAM-MD5 a good idea?实施 CRAM-MD5 是个好主意吗？
【发布时间】：2012-10-26 21:45:50
【问题描述】：

我正在编写一个 SMTP 服务器并实现了 CRAM-MD5 身份验证。为了计算挑战响应字符串，我显然需要在服务器上存储一个明文密码。

这背后的原因是什么？这种身份验证机制似乎存在极大的缺陷，前提是：

CRAM-MD5 要求在服务器上存储纯文本密码
CRAM-MD5 使用了损坏的 MD5

在我看来，CRAM-MD5 确实不如 PLAIN/LOGIN 身份验证安全，前提是始终需要 TLS。

【问题讨论】：

更多的东西给security.stackexchange.com真的。
对，不知道安全站点。好吧，既然它已经在这里发布了，仍然感谢答案/cmets。

标签： cryptography smtp

【解决方案1】：

是的，由于密码重用，存储密码，即使是可逆加密的，也比某种加盐哈希更糟糕。可以说，从明文密码（如通过 PBKDF2 或常规加盐哈希）生成一些内容，然后在双方都使用它会更安全一些。但是，它需要客户端知道服务器的哈希方案，包括用于此帐户的盐。无论你如何分割它，都会留下一些与 CRAM-MD5 不兼容的东西，而且不一定更好。

由于这个问题和其他问题，我建议完全忘记 CRAM-MD5。特别是它使用了MD5，被认为是坏了，还有various known weaknesses。最大的是连接没有加密，所以任何人都可以嗅出实际的内容。

更好的答案是只使用 TLS。

【讨论】：

【解决方案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] 中描述的技术对中间结果进行预计算，可以避免在服务器系统上显式存储共享机密，而是存储称为“上下文”的中间结果

【讨论】：

非常感谢，您的回答很重要！ :)

【解决方案3】：

当然，如果您只想保留不可逆密码作为 CRAM-MD5 的密钥，您可以修改 CRAM-MD5 以使用 PBKDF 函数（例如 PBKDF2）的输出。不过，你需要两面都加盐。

但这并不是很有用，因为攻击者可能会直接使用 PBKDF2 的输出作为 CRAM-MD5 的输入。所以唯一的好处是用户的密码不会直接暴露（密码经常被重复使用）。即使是普通登录，强烈建议在服务器上使用 PBKDF2，因为它可以减轻数据库受损的影响。

当然，将 CRAM-MD5 版本与 KDF 一起使用使其成为专有协议，因此互操作性会受到影响。

但是，由于检索密码意味着破坏 TLS，因此 PLAIN/LOGIN 对于大多数用例来说应该没问题。

请注意，我不是 CRAM-MD5 方面的专家，我只是快速阅读了 Wikipedia 上的协议。

【讨论】：

真的只是想对此提出第二意见，因为身份验证方案似乎存在极大的缺陷。
好吧，因为它本身不验证服务器，所以它的用途似乎有限，尤其是没有其他识别服务器的方法。 TLS 提供了这一点，但在这种情况下，它似乎并没有真正带来太多好处。
那将毫无意义：哈希密码现在，无论出于何种意图和目的，都是实际密码。可以获取哈希的攻击者可以作为该用户进行身份验证。
我认为@NickJohnson 的观点是同样的论点适用于以明文形式存储密码。如果您担心服务器密码存储的保密性，那么存储 PBKDF 将无济于事；如果你不是，那么通过存储明文密码来保持简单和可互操作。
@JameySharp 哎呀，你当然是对的，没关系，我回家后会改变答案