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.
对于那些不了解它的人,SHA代表安全散列算法,这是一种用于加密的标准算法。
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??
我希望它很清楚。问题是:如果我嗅探数据包2和3(“挑战”和“挑战xor密码”,我确实有他们之间的另一个xor的实际密码!?!?还有其他方法来实现这种协议??
10 个解决方案
#1
3
How about the following:
以下怎么样:
- Server sends a random challenge
- Client sends SHA1 checksum of (challenge+password)
- Servers compares against SHA1 checksum of (challenge+stored password)
服务器发送随机质询
客户端发送SHA1校验和(质询+密码)
服务器与SHA1校验和(质询+存储密码)进行比较
#2
4
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?
您可以对密码进行反向工程。您想发送密码的SHA,而不是密码本身。滚动自己的安全协议几乎不是一个好主意。你能不能使用SSL或类似的东西?
#3
2
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.
这是一个非常可怕的协议。如果这是某人希望您实施的内容,请拒绝。对于这种类型的事物,存在经过审查的协议。如果这是一个游戏,你指出所有的缺陷 - 好吧。
- Anyone who hears steps 2 & 3 knows the password
- Anyone who hears step 3 and notes the time can brute-force the password if he has any idea of the precision of the time on the server
- I can pretend to be a server (arp poisoning, dns rediction, etc), and get your password, never completing step 4 and feigning a timeout
- Vulnerable to Man in the Middle Attacks because there's no shared secret between client/server or certificates on the server
- Relies on the server storing the SHA1(time) and waiting for a response, so I can overload the server with requests for challenges and never reply.
任何听过步骤2和3的人都知道密码
如果他知道服务器上的时间精确度,任何听到第3步并注意时间的人都可以强制密码
我可以装作服务器(arp中毒,dns rediction等),并获取你的密码,从不完成第4步并假装超时
在中间攻击中易受攻击,因为客户端/服务器或服务器上的证书之间没有共享密钥
依赖存储SHA1(时间)的服务器并等待响应,因此我可以通过请求挑战来重载服务器,从不回复。
And I'm definetly missing some more.
我肯定会错过一些。
#4
1
You are right -- if you capture the challenge and (challenge XOR password) then extracting the password is easy.
你是对的 - 如果你捕获了挑战并且(挑战XOR密码),那么提取密码很容易。
You need to use proper encryption in step 3, not XOR. Encrypt the challenge with the password.
您需要在步骤3中使用适当的加密,而不是XOR。使用密码加密挑战。
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.
为了使攻击者的生活更加艰难,您可以将随机数据添加到您加密的内容中:例如:加密paddingCHALLENGEpadding。服务器不关心填充是什么,它知道在哪里寻找挑战,但这意味着攻击者不会知道整个明文是什么。
#5
1
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).
正如对方已经指出的那样,你是对的。还要记住,当真实用户遇到网络问题(例如:DDOS)时,有人可以拦截通信(3)并可能重新发送,冒充者将会登录并且通常足以更改密码(即,许多系统不要求您提供密码以便在登录后更改密码。
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(密钥哈希消息身份验证代码)。我在这里详细介绍了它:http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html我将在下面给出一个快速摘要。
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.)
HMAC是一种确保消息由有权访问共享密钥的人生成的方法。 HMAC利用某种单向散列函数(如MD5或SHA-1)来加密秘密和消息。这将生成一个16-20字节的简短摘要,充当消息+秘密组合的指纹。当摘要与消息一起发送时,接收者(我们的服务器)可以使用相同的HMAC计算重新生成散列,并将本地生成的摘要与消息附带的摘要进行比较。请记住:服务器也有秘密,所以它有足够的信息来确认摘要。 (这只考虑验证消息来源的问题,但是如果使用不同的秘密,比如一组公钥,则可以使用相同的方法来加密整个消息。)
#6
0
The way I would do this is the following:
我这样做的方法如下:
- Challenge the server.
-
Server responds with it's public key (for, say RSA encryption) digitally signed.
服务器以数字签名的公钥(例如RSA加密)进行响应。
-
Client verifies PK, and encrypts password with the key, then digitally signs the encrypted password.
客户端验证PK,并使用密钥加密密码,然后对加密密码进行数字签名。
-
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.
数字签名在这里很重要,因为它可以作为防止中间人攻击的开始。
#7
0
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.
您可能想要查看HTTP使用的摘要式身份验证。事实上,如果你的协议是通过HTTP,你可以跳过编写自己的协议,只需使用或实现它。
#8
0
public key encryption? Use the server's public key to encrypt the password.
公钥加密?使用服务器的公钥加密密码。
#9
0
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)
要克服你所面临的问题... F - 一个接受密码和伪随机单调增加值并返回一个数字的函数。对于例如哈希(哈希(密码)^时间戳)
- Server : Ask for Challenge, Send (Timestamp). Remember Last Timestamp Sent.
- Client, Send Response (Send F(Password, Timestamp) and Timestamp)
- Server: Check Client by using Hash(Password) and Timestamp sent by the client (> Timestamp sent in Challenge).
- If Client is correct, grant access.
- Ensure present timestamp is greater than all client sent timestamps before next challenge to prevent replay attacks.
服务器:要求挑战,发送(时间戳)。记住发送的上次时间戳。
客户端,发送响应(发送F(密码,时间戳)和时间戳)
服务器:使用客户端发送的哈希(密码)和时间戳(>挑战中发送的时间戳)检查客户端。
如果客户端正确,则授予访问权限。
确保当前时间戳大于下次质询之前所有客户端发送的时间戳,以防止重放攻击。
Kind regards, Ashish Sharma
亲切的问候,Ashish Sharma
#10
0
I believe the Diffie-hellman is a well-known and solid key exchange protocol?
我相信Diffie-hellman是一个众所周知且坚实的密钥交换协议?
#1
3
How about the following:
以下怎么样:
- Server sends a random challenge
- Client sends SHA1 checksum of (challenge+password)
- Servers compares against SHA1 checksum of (challenge+stored password)
服务器发送随机质询
客户端发送SHA1校验和(质询+密码)
服务器与SHA1校验和(质询+存储密码)进行比较
#2
4
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?
您可以对密码进行反向工程。您想发送密码的SHA,而不是密码本身。滚动自己的安全协议几乎不是一个好主意。你能不能使用SSL或类似的东西?
#3
2
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.
这是一个非常可怕的协议。如果这是某人希望您实施的内容,请拒绝。对于这种类型的事物,存在经过审查的协议。如果这是一个游戏,你指出所有的缺陷 - 好吧。
- Anyone who hears steps 2 & 3 knows the password
- Anyone who hears step 3 and notes the time can brute-force the password if he has any idea of the precision of the time on the server
- I can pretend to be a server (arp poisoning, dns rediction, etc), and get your password, never completing step 4 and feigning a timeout
- Vulnerable to Man in the Middle Attacks because there's no shared secret between client/server or certificates on the server
- Relies on the server storing the SHA1(time) and waiting for a response, so I can overload the server with requests for challenges and never reply.
任何听过步骤2和3的人都知道密码
如果他知道服务器上的时间精确度,任何听到第3步并注意时间的人都可以强制密码
我可以装作服务器(arp中毒,dns rediction等),并获取你的密码,从不完成第4步并假装超时
在中间攻击中易受攻击,因为客户端/服务器或服务器上的证书之间没有共享密钥
依赖存储SHA1(时间)的服务器并等待响应,因此我可以通过请求挑战来重载服务器,从不回复。
And I'm definetly missing some more.
我肯定会错过一些。
#4
1
You are right -- if you capture the challenge and (challenge XOR password) then extracting the password is easy.
你是对的 - 如果你捕获了挑战并且(挑战XOR密码),那么提取密码很容易。
You need to use proper encryption in step 3, not XOR. Encrypt the challenge with the password.
您需要在步骤3中使用适当的加密,而不是XOR。使用密码加密挑战。
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.
为了使攻击者的生活更加艰难,您可以将随机数据添加到您加密的内容中:例如:加密paddingCHALLENGEpadding。服务器不关心填充是什么,它知道在哪里寻找挑战,但这意味着攻击者不会知道整个明文是什么。
#5
1
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).
正如对方已经指出的那样,你是对的。还要记住,当真实用户遇到网络问题(例如:DDOS)时,有人可以拦截通信(3)并可能重新发送,冒充者将会登录并且通常足以更改密码(即,许多系统不要求您提供密码以便在登录后更改密码。
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(密钥哈希消息身份验证代码)。我在这里详细介绍了它:http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html我将在下面给出一个快速摘要。
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.)
HMAC是一种确保消息由有权访问共享密钥的人生成的方法。 HMAC利用某种单向散列函数(如MD5或SHA-1)来加密秘密和消息。这将生成一个16-20字节的简短摘要,充当消息+秘密组合的指纹。当摘要与消息一起发送时,接收者(我们的服务器)可以使用相同的HMAC计算重新生成散列,并将本地生成的摘要与消息附带的摘要进行比较。请记住:服务器也有秘密,所以它有足够的信息来确认摘要。 (这只考虑验证消息来源的问题,但是如果使用不同的秘密,比如一组公钥,则可以使用相同的方法来加密整个消息。)
#6
0
The way I would do this is the following:
我这样做的方法如下:
- Challenge the server.
-
Server responds with it's public key (for, say RSA encryption) digitally signed.
服务器以数字签名的公钥(例如RSA加密)进行响应。
-
Client verifies PK, and encrypts password with the key, then digitally signs the encrypted password.
客户端验证PK,并使用密钥加密密码,然后对加密密码进行数字签名。
-
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.
数字签名在这里很重要,因为它可以作为防止中间人攻击的开始。
#7
0
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.
您可能想要查看HTTP使用的摘要式身份验证。事实上,如果你的协议是通过HTTP,你可以跳过编写自己的协议,只需使用或实现它。
#8
0
public key encryption? Use the server's public key to encrypt the password.
公钥加密?使用服务器的公钥加密密码。
#9
0
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)
要克服你所面临的问题... F - 一个接受密码和伪随机单调增加值并返回一个数字的函数。对于例如哈希(哈希(密码)^时间戳)
- Server : Ask for Challenge, Send (Timestamp). Remember Last Timestamp Sent.
- Client, Send Response (Send F(Password, Timestamp) and Timestamp)
- Server: Check Client by using Hash(Password) and Timestamp sent by the client (> Timestamp sent in Challenge).
- If Client is correct, grant access.
- Ensure present timestamp is greater than all client sent timestamps before next challenge to prevent replay attacks.
服务器:要求挑战,发送(时间戳)。记住发送的上次时间戳。
客户端,发送响应(发送F(密码,时间戳)和时间戳)
服务器:使用客户端发送的哈希(密码)和时间戳(>挑战中发送的时间戳)检查客户端。
如果客户端正确,则授予访问权限。
确保当前时间戳大于下次质询之前所有客户端发送的时间戳,以防止重放攻击。
Kind regards, Ashish Sharma
亲切的问候,Ashish Sharma
#10
0
I believe the Diffie-hellman is a well-known and solid key exchange protocol?
我相信Diffie-hellman是一个众所周知且坚实的密钥交换协议?