budgefeeney wrote:If I transmit the new password using just MD5, an eavedropper will know the MD5 hash of the new password.
And if you read my tutorial, I specifically say that thats what CHAP is for - you exchange a secret.
More detail below..
budgefeeney wrote:
Using this they
1) connect to the login page - this gives them the salt
2) They modify the source. The original source hashes the user entered password, combines it with the salt, and hashes the result
The modified source will combine the password hash they found via eavesdropping, combine it with the salt, and hash the result.
3) they load up this modified page and hit submit
4) they login
And you've failed to do a chap sequence.
CHAP - Challenge, Handshake authentication protocol.
1) Connect to the login page
2) The login page sends a unique TIME-BASED code
3) The user, via the form, enters his password
4) The form, using javascript, hashes his password WITH the time-based code, which is unique, and already stored.
5) If it matches, then a session is created - he is securely logged in.
6) As part of creating that session, the time-based code is deleted from the server.
An attacker would have to sniff both transactions - getting the time-based code, and getting the password from the user before it is sent to the server. Then he would have to reply - BEFORE THE USER DOES - to get the session.
Once the session is securely established, changing the password is just a repeat of the above. You send him a secret - the time-based code, and he replies with the old password, and the new password, both hashed with that time-based code.
budgefeeney wrote:
It is for this reason that when I'm saving a NEW password, it is NOT sufficient to hash it, as an attacker can login if they have the hashed password.
You chose a poor salt for your hash. If the salt is time-based, and short-lived, the attacker can't replay - which I mentioned in my tutorial.
budgefeeney wrote:
If you look at the page you referred me to (
http://pajhome.org.uk/crypt/md5/chaplogin.html), the author is aware of this problem too, thus his dream system makes mention of the following:
Change password with Rijndael using old password as key
This is exactly what I'm trying to do, but I'm not too bothered with heavy encryption, given that the "plaintext" is a hash. 3DES would be good enough.
He wants that as an ideal, to replace SSL. He ALSO notes that the CHAP system I described (using just md5, with time-based salts) is being used by Yahoo in areas where SSL isnt used.