Hacker News new | past | comments | ask | show | jobs | submit login

>then hash(password) can just be used in a replay attack.

If password is sent over HTTP in plaintext, then password can be used in a replay attack.

Of course you can also do a dozen other things with it, such as attack other sites.

And of course this flaw is trivially rectified by having the site send a nonce.




The nonce can be replayed too. Just use HTTPS and (as a user) don't re-use passwords.


If the server sends a nonce and the browser/client responds with hash(password + nonce), a replay attack is not possible.


Yeah, but then the server must know the plaintext password to check the client reply, which is exactly the problem password hashing schemes were designed to solve.


That issue is solved by simply having "hash(password+salt)" the thing the server has stored and is checking.

In other words you can combine salts + hashes + nonces to both eliminate the server's need to know the password and the possibility of a replay attack.


Technically, you should be doing hash(hash(password) + nonce). The server should not know the password, only the password's hash.


That just turns hash(password) into the effective plain text password, which the server must know in this scheme.


Correct. The server should be storing the password hashed as Hash(Password+Salt) to make it impractical for an attacker to recover the user's password.

Recovering whatever the server has stored is typically going to be sufficient to authenticate the user, but storing it as a hash mitigates some threats.


The point of a nonce is that it is onetime, and the point of an HMAC / MAC is that an attacker cannot properly utilize the nonce.

Put plainly, nonces are countermeasures specifically for replay attacks and they work.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: