The way I understand password security is that the user enters a password, which
ID: 659918 • Letter: T
Question
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?
Explanation / Answer
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).
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.