2

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

这背后的原因是什么？这种身份验证机制似乎存在令人难以置信的缺陷，前提是：

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

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

4

3 回答 3

3

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

由于这个问题和其他问题，我建议完全忘记 CRAM-MD5。特别是它使用了MD5，被认为是损坏的，并且存在各种已知的弱点。最大的是连接没有加密，所以任何人都可以嗅出实际的内容。

更好的答案是只使用 TLS。

于 2012-11-07T20:50:49.880 回答
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] 中描述的技术对中间结果进行预计算，可以通过存储称为“上下文”的中间结果来避免在服务器系统上显式存储共享秘密

于 2013-03-12T19:57:54.067 回答
0

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

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

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

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

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

于 2012-11-06T21:48:44.090 回答