背景:我当前的服务器提供商告诉我,将密码以纯文本形式存储在数据库中是没有问题的,他说他必须这样做,因为他们使用 CRAM-MD5 进行电子邮件身份验证。我的大脑不同意。但是有些事情告诉我,以纯文本格式将密码存储在数据库中可能不是这里出现的唯一安全问题,我什至不确定现在 CRAM-MD5 是否仍然可以被认为是“安全的”。
无论你能给我什么反馈——从信息安全的角度来看——关于“在不使用 SSL 连接的情况下与电子邮件服务器交谈时使用 CRAM-MD5 进行身份验证”将不胜感激。提前致谢。
背景:我当前的服务器提供商告诉我,将密码以纯文本形式存储在数据库中是没有问题的,他说他必须这样做,因为他们使用 CRAM-MD5 进行电子邮件身份验证。我的大脑不同意。但是有些事情告诉我,以纯文本格式将密码存储在数据库中可能不是这里出现的唯一安全问题,我什至不确定现在 CRAM-MD5 是否仍然可以被认为是“安全的”。
无论你能给我什么反馈——从信息安全的角度来看——关于“在不使用 SSL 连接的情况下与电子邮件服务器交谈时使用 CRAM-MD5 进行身份验证”将不胜感激。提前致谢。
CRAM-MD5 要求服务器知道实际密码,而不仅仅是哈希函数的密码图像。因此,如果服务器必须支持 HMAC-MD5,它必须以明文形式存储密码。(服务器可以加密密码,但由于它还必须知道加密密钥,这无济于事。)
CRAM-MD5 旨在避免以明文形式传输密码。它为被动攻击者提供了一定程度的保护。如果攻击者可以窃听通信但不能注入消息,那么她得到的只是一个挑战 C 和值 HMAC-MD5(P, C),其中 P 是密码。没有更好的方法可以通过蛮力从这些信息中找到密码。然而,蛮力是密码的一个问题:至少应该使用一个缓慢的函数,并且无论如何都应该避免暴露哈希,并且应该被视为一种妥协。
正如Adnan所指出的,存储在服务器上的“密码”(更准确地说是共享秘密)可能是人工密码的慢散列,而不是人工选择的、令人难忘的密码. 这将排除来自 MD5 哈希的蛮力攻击,因此它将为被动攻击者提供更好的安全性。(但是,任何这样做的人都在使用非标准工具,并且可能对使用 SSL 的安全性足够认真。) CRAM-MD5 仅对身份验证步骤进行身份验证,而不对会话的其余部分进行身份验证。因此,能够冒充客户端的主动攻击者可以让身份验证发生,然后切断客户端(或发送修改后的数据)并在会话中发送他自己的命令。具体来说,攻击者必须能够接收发往客户端的 TCP 数据包。或者,攻击者必须能够接收发往服务器的 TCP 数据包,或者发送虚假的 DNS 响应,导致客户端与攻击者而不是服务器进行通信;这样的攻击者在身份验证阶段充当客户端和服务器之间的中继,然后可以继续与服务器通信。顺便说一句,这些攻击都不涉及密码泄露,除了通过上述的蛮力攻击。
在 SSL 上使用 CRAM-MD5 将解决此身份验证问题。SSL 提供了一个安全会话(即参与者在会话期间不能更改),并向客户端验证服务器(假设用户不会盲目接受无效证书)。CRAM-MD5带来了认证问题的第三部分:用服务器认证客户端。
如果密码是一个足够长的随机生成的字符串,那么基于 SSL 的 CRAM-MD5 就可以了——足够长以抵抗暴力破解。如果密码是随机生成的,则没有理由不将其以明文形式存储在服务器上,它只是一个密钥。如果密码是人类可以记住的密码,那么 CRAM-MD5 就很糟糕,因为大多数人类密码都可以通过暴力破解,并且由于它们经常被重复使用而在一台服务器之外很有价值。
如果使用 SSL,与让客户端通过 SSL 连接发送密码相比,使用 CRAM-MD5 几乎没有价值。有一个小的优势是,如果客户端无意中将密码发送给服务器模拟者,密码本身不会立即泄露(仅在被破解的情况下——尽管请注意服务器模拟者可以发送一个持续的挑战并因此构建一个表(彩虹或其他)HMAC-MD5 值而不是似是而非的密码)。在密码是随机字符串的情况下,这可能是一个优势(攻击者不能使用客户端发送的值来模拟它,除非服务器碰巧发送了与攻击者相同的挑战,这不应该发生)。如果密码是人类密码,
在这种情况下,存在三个相关的弱点:
密码存储不当:如果您的提供商的数据库遭到破坏,您的密码就会直接暴露。尽管 CRAM-MD5 的某些实现不以明文形式存储密码,但散列后的密码仍然是未加盐的。到目前为止,还没有已知的对密码进行加盐的实现(客户端也需要知道加盐)。
实际数据以明文形式传输:不使用 SSL,您的电子邮件将完全暴露给MiTM。
离线攻击:一旦攻击者获得了用于认证的信息(服务器发送的挑战,客户端发送的响应),他就可以暴力破解密码离线。
选择明文攻击:因为攻击者能够冒充服务器,他也能够发送他想要的挑战值,并观察客户端的响应。这使得最终知道密码变得更容易。
请注意,这些攻击都与 MD5 本身的漏洞无关。
总之: CRAM-MD5 根本不安全。您的提供商没有理由以明文形式存储密码,这里的问题只是他们不愿实施更好的解决方案。
它没有提供针对 MITM 的保护,因为攻击者可以将挑战转发给客户端。要求明文密码存储是不好的,交易所可能会对其进行字典攻击。
你有理由担心这个方案,我个人建议使用不同的电子邮件提供商。
首先,没有必要使用明文:
您至少可以存储密码的修改版本:
if (length(key) > blocksize) then
key = hash(key) // keys longer than blocksize are shortened
end if
if (length(key) < blocksize) then
key = key ∥ [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded ('∥' is concatenation)
end if
o_key_pad = [0x5c * blocksize] ⊕ key // Where blocksize is that of the underlying hash function
i_key_pad = [0x36 * blocksize] ⊕ key // Where ⊕ is exclusive or (XOR)
存储两个异或的密钥,这样可以增加安全性,即如果您的系统受到威胁,其他地方使用相同密码的用户帐户也不会受到威胁。显然 Dovecot 就是这样做的。
MD5 本身很容易暴力破解。MITM 攻击者可以暴力破解密码,因为他/她已经知道挑战。
如今,几乎所有此类问题的解决方案都是使用 SSL。