The way I understand password security is that the user enters a password, which is then converted using a hash function. The website then compares it to the stored hash to see if it is correct.
That way only the hash is stored, so if an attacker learns that they don't have the original password. Where exactly is it converted to a hash? If it is done clientside, I would expect that an
attacker who knows the hash could modify clientside code to send that directly to the server.
But if done serverside, then the plaintext password has to be sent across the network,
which seems like it is a security problem if an attacker is able to listen to the connection.
Which of these methods is used, and how are the potential security flaws addressed?
- 113
- 3
-
Hashing is done server-side. Integrity and confidentiality of the connection is handled by TLS — encryption of the communication layer. – Stephen Touset Aug 16 '14 at 18:07
-
Here's why it should not be done client-side: http://security.stackexchange.com/a/64854/22401. That's why it should be done server-side and credentials should be sent to sever over SSL. – Rahil Arora Aug 16 '14 at 18:09
-
@StephenTouset Sometimes it's done on client side when HTTP authentication with Digest method is used for example. – Hunsu Aug 16 '14 at 18:10
2 Answers
Yes, your first answer is correct -- if done client-side, you've then its essentially the hash of the password is the password.
The usual practice is to do it serverside via HTTPS. Yes, people on the server side can in principle see your password, but they also have full access to all the data your password can see/change. This is a very good reason to never re-use passwords at different sites and to use a random passwords for each site kept in an encrypted password manager (like keepass).
Note there is a third option, the Secure Remote Password Protocol which is more complicated, but prevents both of the attacks described above. It requires both client-side and server-side hashing and uses modular exponentiation (similar to a diffie-hellman key exchange). Granted, at the moment the SRP is not widely used as it isn't built into webbrowsers yet (and doing it in JS allows a straightforward attack from the server-side by changing the JS to something that sends the password in plaintext from the browser).
- 38,768
- 8
- 92
- 161
-
1Another protocol where the hashing is done client-side: [SCRAM](https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism), its an IETF SASL standard, but not supported by any browser, as the HTTPS standardisation [has stalled](https://datatracker.ietf.org/doc/draft-melnikov-httpbis-scram-auth/). – user10008 Aug 16 '14 at 19:05
In webapps it's normally done on the server side. The cleartext password is sent to the server, then server code salts and hashes it.
Secure Remote Password is a much better approach, but it's still subject to brute force attacks with frequent passwords to recover the user's cleartext password if the attacker has access to the server.
An even better approach is multi-party secret strengthening, which results in a cryptographically strong credential (based on a password with no client-side storage) that can not be dictionary attacked unless all parties collude against the user. I'm not aware of any widely adopted implementations, though.
- 1,313
- 9
- 10