安全、密码学：愚蠢的挑战 - 响应协议？
好吧，大家只是一个小游戏：
我有一个项目的一些规范。 在某些时候，他们要求以下内容通过网络加密密码，并称这是一个质询响应协议：
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（“挑战”和“挑战异或密码”），我确实得到了实际密码，只是在它们之间进行了另一个异或！？！？还有其他方法来实现这种协议??
Ok guys just a small game:
I have some specifications for a project. At some point they ask for the following to encrypt a password over the net, saying that it is a challenge response protocol:
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
For those who don't know it SHA stands for Secure Hashing Algorithm, a standard algorithm for cryptography.
I hope it's clear. Question is: If I sniff packets 2 and 3 (the "challenge" and the "challenge xor password", I do have the actual password just with another xor between them both!?!? There is other way to implement this kind of protocol??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我这样做的方法如下：
服务器用它的公钥进行响应
（例如 RSA 加密）数字方式
已签名。
客户端验证PK并加密
密码与密钥，然后
对加密的内容进行数字签名
密码。
服务器验证签名并解密
用于存储/检查它的密码。
数字签名在这里很重要，因为它是防止中间人攻击的开始。
The way I would do this is the following:
Server responds with it's public key
(for, say RSA encryption) digitally
signed.
Client verifies PK, and encrypts
password with the key, then
digitally signs the encrypted
password.
Server verifies signing and decrypts
the password to store/check it.
The digital signing is important here as it acts as the beginning of preventing man in the middle attacks.
正如其他人指出的那样，是的，这是一个糟糕的挑战响应算法。
您可能想查看 HTTP 使用的 摘要式身份验证。 事实上，如果您的协议基于 HTTP，您可以跳过编写自己的协议，而只需使用或实现它。
As others have pointed out, yes, this is a poor challenge response algorithm.
You probably want to check out Digest Authentication, as used by HTTP. In fact, if your protocol is over HTTP, you can skip writing your own and just use or implement this.
公钥加密？ 使用服务器的公钥对密码进行加密。
public key encryption? Use the server's public key to encrypt the password.
虽然推出自己的加密协议从来都不是一个好的解决方案，而且我也不建议这样做......
为了克服你面临的问题......
F - 接受密码和伪随机单调递增值并返回一个数字的函数。 例如 Hash(Hash(Password) ^ Timestamp)
亲切的问候，
阿什什·夏尔马
Although it is never a good solution to roll out your own cryptographic protocol, and it is something I would not suggest....
To overcome the problem that you are facing...
F - A function which takes in the password and a pseudorandom monotonically increasing value and returns a number. For e.g. Hash(Hash(Password) ^ Timestamp)
Kind regards,
Ashish Sharma
我相信 Diffie-hellman 是一个众所周知且可靠的密钥交换协议？
I believe the Diffie-hellman is a well-known and solid key exchange protocol?
您将能够对密码进行逆向工程。 您想要发送密码的 SHA，而不是密码本身。 推出自己的安全协议几乎从来都不是一个好主意。 不能使用 SSL 或类似的东西吗？
You would be able to reverse engineer the password. You want to send the SHA of the password, not the password itself. Rolling your own security protocols is almost never a good idea. Can you not use SSL or something equivalent?
http://en.wikipedia.org/wiki/Cryptographic_nonce
以下情况如何：
How about the following:
这是一个非常可怕的协议。 如果这是有人希望你实施的事情，请拒绝。 对于此类事情，已有经过审查的现有协议。 如果这是一款你需要指出所有缺陷的游戏——好吧。
我肯定还缺少一些。
That's a pretty horrible protocol. If this is something someone wants you to implement, refuse to. There are existing, vetted protocols for this type of thing. If this is a game where you point out all the flaws - okay.
And I'm definetly missing some more.
你是对的——如果你捕获了挑战和（挑战异或密码），那么提取密码就很容易了。
您需要在步骤 3 中使用适当的加密，而不是 XOR。 使用密码加密质询。
为了让攻击者的日子变得更难，您可以将随机数据添加到您加密的内容中：例如加密 paddingCHALLENGEpadding。 服务器不关心填充是什么，它知道在哪里寻找挑战，但这意味着攻击者不会知道整个明文是什么。
You are right -- if you capture the challenge and (challenge XOR password) then extracting the password is easy.
You need to use proper encryption in step 3, not XOR. Encrypt the challenge with the password.
To make an attacker's life harder you could add random data to what you encrypt to: e.g. encrypt paddingCHALLENGEpadding. The server doesn't care what the padding is, it knows where to look for the challenge, but it means an attacker won't know what the whole plaintext is.
正如其他人所指出的，你是对的。 另请记住，有人可能会拦截通信 (3) 并可能在真实用户遇到网络问题（例如：DDOS）时重新发送该通信，冒名顶替者随后会登录，并且通常足以更改密码（即，许多系统不需要您提供密码以便在登录后更改密码）。
您可能需要考虑 HMAC（密钥哈希消息身份验证代码）。 我在这里详细介绍了它： http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html 我将在下面给出一个快速总结。
HMAC 是一种确保消息是由有权访问共享秘密的人生成的方法。 HMAC 使用某种单向散列函数（如 MD5 或 SHA-1）来加密秘密和消息。 这会生成一个 16-20 字节的短摘要，充当消息+秘密组合的指纹。 当摘要与消息一起发送时，接收者（我们的服务器）可以使用相同的 HMAC 计算重新生成哈希，并将本地生成的摘要与消息附带的摘要进行比较。 请记住：服务器也有秘密，因此它有足够的信息来确认摘要。 （这仅考虑验证消息来源的问题，但如果您使用不同的秘密，例如一组公钥，则可以使用相同的方法来加密整个消息。）
As the other's have pointed out, you are correct. Also keep in mind that someone could intercept communication (3) and potentially resend it while the real user is experiencing network issues (eg: a DDOS), the impostor would then be logged in and often that is sufficient to change the password (that is, many systems don't require that you supply a password inorder to change it once you are logged in).
You may want to consider HMAC (keyed-Hash Message Authentication Code). I've blogged about it in detail here: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html and I'll give a quick summary below.
HMAC is a method of ensuring that a message was generated by someone with access to a shared secret. HMAC makes use of some sort of one-way hashing function (like MD5 or SHA-1) to encrypt the secret along with a message. This generates a short digest of 16-20 bytes that acts as a fingerprint of the message+secret combination. When the digest is sent along with the message, the receiver (our server) can re-generate the hash with the same HMAC calculation and compare the locally generated digest with the digest that came along with the message. Remember: the server has the secret too, so it has enough information to confirm the digest. (This only considers the problem of verifying the origin of a message, but you can use the same approach to encrypt the entire message, if you use a different secret, say a set of public keys.)