我得到的建议是我怀疑的,所以我在这里寻找支持,回去挑战这个建议。
有人建议我使用Diffie-Helman让双方就密钥达成一致,使用该密钥生成AES密钥,然后使用AES对正在传输的密码进行加密/解密。与示例代码here非常相似
当使用该方案时,加密密码的长度与未加密密码的长度相同。我应该为此担心吗?
在此之前,我使用的是RSA,用接收方的公钥加密密码。无论密码长度是多少,这都会导致加密长度为256。这样不是更好吗?
发布于 2010-01-19 21:49:08
首先:不要发明自己的身份验证协议。句号。如果你这样做,即使你使用的是强加密,你也会弄错。有许多现有的记录良好的认证协议已经被密码学家审查,因此被认为是安全的。不要试图“简化”它们,它们已经被简化了。
第二:我不应该在网络上发送密码进行身份验证(我不知道有任何身份验证协议会这样做,包括可怕的不安全的NTLMv1协议)1。
如果你坚持“使用我自己的身份验证方案”,下面是我如何让你上面描述的方案更安全(警告:我不是密码学家-我相信我在这里描述的方案中有严重的弱点):
不是直接发送密码,而是发送密码的单向函数(也称为OWF,通常实现为SHA256或更强的加密散列)。
换句话说,让服务器向客户机发送盐值,将盐添加到密码,计算OWF值的password+salt,并将OWF结果发送到服务器。在服务器上,将盐添加到密码,并执行OWF计算。如果结果相同,则密码有效;如果结果不一致,则密码无效。
最后,让真正的密码学家审查你所做的一切。他们会在你的实现中发现问题,你将不得不修复它们。他们可能会建议您放弃您的努力,转而支持现有的已发布协议。
1 AFAIK,你应该在网络上发送密码的唯一时间是当你更改密码时,即使在那时,你也应该将长度填充到块大小的倍数(包括在cybertext中的长度,以便当您解密它时,您可以区分密码和填充)。
https://stackoverflow.com/questions/2093726
复制相似问题