代码之家 › 专栏 › 技术社区 › Pablo Herrero

安全,密码学:愚蠢的挑战-响应协议?

challenge-response cryptography security

Pablo Herrero · 技术社区 · 17 年前

好了,伙计们,只是一个小游戏:

我有一个项目的一些规格。在某些时候,他们要求通过以下方式在网络上加密密码,称这是一种挑战-响应协议:

CLIENT ----------------------------- SERVER

(1)ask for challenge -------------->

(2)    <---------------------------- send SHA1 taken from the time
                                       (this is the challenge)
(3) make SHA1 xor PASSWORD --------> if it's equal to SHA1 xor stored password

(4)    <---------------------------- Grant access

对于那些不知道它的人来说,SHA代表安全散列算法,这是一种密码学的标准算法。

我希望这很清楚。问题是:如果我嗅探数据包2和3(“挑战”和“挑战xor密码”),我确实有实际的密码,只是它们之间有另一个xor!??还有其他方法来实现这种协议吗??

10 回复 | 直到 7 年前

Greg Dean 17 年前

您可以对密码进行反向工程。您要发送密码的SHA,而不是密码本身。制定自己的安全协议几乎从来都不是一个好主意。你不能使用SSL或等效的东西吗?

http://en.wikipedia.org/wiki/Cryptographic_nonce

Bruno De Fraine 17 年前

以下情况如何:

服务器发送随机质询
客户端发送(质询+密码)的SHA1校验和
服务器与SHA1校验和(质询+存储密码)进行比较

Tom Ritter 17 年前

这是一个相当可怕的协议。如果这是有人想让你实施的,拒绝。这类事情有现有的、经过审查的协议。如果这是一个你指出所有缺陷的游戏——好吧。

任何听到步骤2的人;3知道密码
任何听到步骤3并记下时间的人,如果知道服务器上时间的准确性,都可以强行破解密码
我可以假装是服务器(arp中毒、dns预测等),并获取您的密码,永远不会完成步骤4并假装超时
易受中间人攻击,因为客户端/服务器或服务器上的证书之间没有共享机密
依赖于服务器存储SHA1(时间)并等待响应,因此我可以用挑战请求使服务器过载,而永远不会回复。

我确实错过了更多。

Rob Walker 17 年前

你说得对——如果你捕捉到挑战并(挑战XOR密码),那么提取密码就很容易了。

您需要在步骤3中使用正确的加密,而不是XOR。用密码加密挑战。

为了使攻击者的生活更加艰难,您可以在加密对象中添加随机数据:例如加密填充CHALLENGEPiding。服务器不在乎填充是什么,它知道在哪里寻找挑战,但这意味着攻击者不知道整个明文是什么。

rcreswick 17 年前

正如其他人所指出的那样,你是对的。还要记住,当真实用户遇到网络问题(例如:DDOS)时,有人可能会拦截通信(3)并可能重新发送,然后冒名顶替者将登录,这通常足以更改密码(也就是说,许多系统不要求您在登录后提供密码进行更改)。

您可能需要考虑HMAC(密钥哈希消息身份验证码)。我在这里详细写了博客: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html 下面我会做一个简短的总结。

HMAC是一种确保消息是由有权访问共享密钥的人生成的方法。HMAC使用某种单向散列函数(如MD5或SHA-1)来加密消息中的秘密。这将生成一个16-20字节的简短摘要,作为消息+秘密组合的指纹。当摘要与消息一起发送时,接收方(我们的服务器)可以使用相同的HMAC计算重新生成哈希,并将本地生成的摘要与消息附带的摘要进行比较。记住:服务器也有秘密,所以它有足够的信息来确认摘要。(这只考虑了验证消息来源的问题,但如果你使用不同的秘密,比如一组公钥,你可以使用相同的方法加密整个消息。)

workmad3 17 年前

我这样做的方式如下:

挑战服务器。
服务器使用其公钥进行响应 (例如RSA加密)数字签署。
客户端验证PK并加密使用密钥输入密码,然后对加密内容进行数字签名密码。
服务器验证签名并解密存储/检查密码。

数字签名在这里很重要,因为它是防止中间人攻击的开始。

Nick Johnson 17 年前

正如其他人指出的那样,是的,这是一个糟糕的挑战-响应算法。

你可能想看看 Digest Authentication ,如HTTP所使用的。事实上,如果你的协议是基于HTTP的,你可以跳过编写自己的协议,直接使用或实现它。

axel_c 17 年前

公钥加密?使用服务器的公钥加密密码。

SharePoint Newbie 17 年前

尽管推出自己的加密协议从来不是一个好的解决方案,而且我也不建议这样做。...

克服你面临的问题。.. F-一个函数,它接受密码和一个伪随机单调递增的值,并返回一个数字。例如哈希(哈希(密码)^时间戳)

服务器:请求质询,发送(时间戳)。记住上次发送的时间戳。
客户端,发送响应(发送F(密码、时间戳)和时间戳)
服务器:使用客户端发送的哈希(密码)和时间戳(>质询中发送的时间戳)检查客户端。
如果客户端正确,则授予访问权限。
确保当前时间戳大于下一次质询前所有客户端发送的时间戳,以防止重放攻击。

亲切问候, Ashish Sharma

Paul Nathan 16 年前

我相信Diffie hellman是一个众所周知且可靠的密钥交换协议?