views:

439

answers:

10

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??

+4  A: 

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

Greg Dean
Nonces are like temporary salts :)
Jeremy Powell
+1  A: 

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.

Rob Walker
yeah but... how i undo the SHA1 once the password is in the server side???
pabloh84
That is a predictable pattern that can be exploited. Not a good idea.
Paul Nathan
security through obscurity is not security at all
Greg Dean
In the question I don't see where the SHA1 part matters - the challenge can be anything. You don't need to undo the hashing unless I am misunderstanding the description.Where is the obscurity part? Adding padding is the same as using a salt in storing a password to prevent known plaintext attacks.
Rob Walker
The problem is that xor is intrinsically reversible. If you have pw^s1hash and s1hash separately then you can recover pw by doing pw^s1hash^s1hash to undo the original xor. (^ here is an xor operation)
workmad3
@pabloh84: if you replace xor with say, SHA1, then you just do the same SHA1 on both sides. As others have indicated, you need a one-way operation (at the very least) instead of XOR.
rcreswick
@Rob WalkerSalt increases the entropy of a hashed password. Padding the password with random bytes, does nothing but obscure the message. For example once someone figures out the password needs to be padded, doing so provides no benefit
Greg Dean
@gdean2323 -- I wasn't padding the password, I was suggesting padding the challenge and _then_ encrypting it (using a 'proper' encryption algorithm, not XOR).
Rob Walker
Regardless, the padding adds nothing from a security perspective. You may as well just said use 'proper' encryption.
Greg Dean
+1  A: 

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.

And I'm definetly missing some more.

Tom Ritter
+1  A: 

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.)

rcreswick
+1  A: 

How about the following:

  1. Server sends a random challenge
  2. Client sends SHA1 checksum of (challenge+password)
  3. Servers compares against SHA1 checksum of (challenge+stored password)
Bruno De Fraine
A: 

The way I would do this is the following:

  1. Challenge the server.
  2. Server responds with it's public key (for, say RSA encryption) digitally signed.

  3. Client verifies PK, and encrypts password with the key, then digitally signs the encrypted password.

  4. 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.

workmad3
This _doesn't_ prevent man in the middle attacks, as a man in the middle can substitute the client or server's key for its own, unless you have a CA - in which case, you just recreated SSL (and should be using that instead).
Nick Johnson
A: 

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.

Nick Johnson
A: 

Hello, public key encryption? Use the server's public key to encrypt the password.

axel_c
A: 

Hi,

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)

  1. Server : Ask for Challenge, Send (Timestamp). Remember Last Timestamp Sent.
  2. Client, Send Response (Send F(Password, Timestamp) and Timestamp)
  3. Server: Check Client by using Hash(Password) and Timestamp sent by the client (> Timestamp sent in Challenge).
  4. If Client is correct, grant access.
  5. Ensure present timestamp is greater than all client sent timestamps before next challenge to prevent replay attacks.

Kind regards, Ashish Sharma

SharePoint Newbie
A: 

I believe the Diffie-hellman is a well-known and solid key exchange protocol?

Paul Nathan