Ok, I put together a description of the possible uses of hashing on passwords and login authentication processes and what the help with or not...
Code:
pwd = cleartext password
pwd-hash = md5'ed password resulting hash
hash-hash = pwd-hash re-hash
hash2-hash = pwd-hash, re-hash, re-hash
chlg = "Challenge-text": sufficient length of random characters
resp-hash = challenge + pwd hash
--submit--> = password submition
--md5--> = hashing process
<--compare-- = compare from stored password
<--sends-- = server sent data
+ = "Append with"
Scenario 1: pwd sent in clear, stored as cleartext, databse is compromised
client | server | database
pwd --submit--> pwd <--compare-- pwd
hacker | server | database
pwd --sumbit--> pwd <--compare-- pwd
Result: login successful
Scenario 2: pwd sent in clear, stored as hash, databse is compromised
client | server | database
pwd --submit--> pwd --md5--> pwd-hash <--compare-- pwd-hash
hacker | server | database
pwd-hash --sumbit--> pwd-hash --md5--> hash-hash <--compare-- pwd-hash
Result: comparaison doesn't match, login denied
Scenario 3: pwd sent in clear, stored as cleartext or hash, transmission intercepted
client | server | database
pwd --submit--> pwd --md5--> pwd-hash <--compare-- pwd-hash
pwd --submit--> pwd <--compare-- pwd
hacker | server | database
pwd --submit--> pwd --md5--> pwd-hash <--compare-- pwd-hash
pwd --submit--> pwd <--compare-- pwd
Result: in both cases comparaison matches, login successful
Scenario 4: pwd sent as hash, which is stored as-is (cleartext), transmission intercepted OR database compromised
client | server | database
pwd --md5--> pwd-hash --submit--> pwd-hash <--compare-- pwd-hash
hacker | server | database
pwd-hash --submit--> pwd-hash <--compare-- pwd-hash
Result: comparaison matches, login successful
Scenario 5: pwd sent as hash, which is re-hashed before being stored, database compromised
client | server | database
pwd --md5--> pwd-hash --submit--> pwd-hash --md5--> hash-hash <--compare-- hash-hash
hacker | server | database
hash-hash --submit--> hash-hash --md5--> hash2-hash <--compare-- hash-hash
Result: comparaison doesn't matche, no login
Scenario 6: pwd sent as hash, which is re-hashed before being stored, transmission intercepted
client | server | database
pwd --md5--> pwd-hash --submit--> pwd-hash --md5--> hash-hash <--compare-- hash-hash
hacker | server | database
pwd-hash --submit--> pwd-hash --md5--> hash-hash <--compare-- hash-hash
Result: comparaison matches, login successful
Scenario 7: challenge/repsonse style authentication, password stored as hash, transmission intercepted
client | server | database
chlg1 <--sends-- chlg1 pwd-hash
pwd --md5--> pwd-hash+chlg1 --md5--> resp-hash --submit--> resp-hash <--compare--> resp-hash <--md5-- pwd-hash+chlg1 <---- pwd-hash
client | server | database
chlg2 <--sends-- chlg2 pwd-hash
resp-hash ???? --submit--> ????????? <--compare--> resp-hash <--md5-- pwd-hash+chlg2 <---- pwd-hash
Result: nothing much to do with the response hash! login failes
Scenario 8: challenge/repsonse style authentication, password stored as hash, database compromised (aka: "Passing the hash")
client | server | database
chlg1 <--sends-- chlg1 pwd-hash
pwd --md5--> pwd-hash+chlg1 --md5--> resp-hash --submit--> resp-hash <--compare--> resp-hash <--md5-- pwd-hash+chlg1 <---- pwd-hash
hacker | server | database
chlg2 <--sends-- chlg2 pwd-hash
pwd-hash +chlg2 --md5--> resp-hash --submit--> resp-hash <--compare--> resp-hash <--md5-- pwd-hash+chlg2 <---- pwd-hash
Result: comparaison matches, login successful
Moral of the story:
Protection || Login info vulnerable* in
Client-side | Server-side || Transmision | Database
-------------------------------------------------------
Cleartext | Cleartext || y | y
Cleartext | MD5 hash || y | n
MD5 hash | Cleartext** || y | y
MD5 hash | MD5 hash*** || y | n
Chlg/Rexp | MD5 hash || n | y
* Might not be cleartext password but login possible with that info
** Stored as received from client
*** Re-hashed a second time