Why web apps don’t use double hashing for password
tags: learning programming authentication confusion
content
question
- In a typical web app, password is sent from client to server without hashing
- if there’s no hashing, the server can see user’s exact password!
- i know that we are trusting the server to NOT log or store the password (really, purely trust), but why not hash the password at client side before sending to server?
- this way, server would never see client’s password, isn’t it?
- and if the server never sees the password, that means it CANNOT use client’s password to guess the client’s password on other website
- my confusion: why not do double hashing then??
What client side hashing is doing:
- protect against server side logging/storing of user password
- hence, protecting against malicious sys admin on server side (who might try user’s password on other website)
Answers
- trust on server
- if it’s a web app, the website’s javascript is sent by the server, that means we are trusting the server to implement hashing.
- If the server is malicious (if it’s gonna try user’s password on other website), it’s not gonna send a javascript with proper client side hashing anyways
- malicious server would just not hash!
- cost of client side hashing
- if it’s a simple hashing algo, there’s no point doing it because it’s too easy to brute force
- if it’s a complex hashing, it’s gonna be CPU-intensive, some are even memory heavy
- it might take too long and affect user experience (we don’t know what device client is using, might be a shitty one!)
- client side hashing has its own technical implementation challenges, hard to do right!
Note
- It’s true that client side hashing guarantees that server NEVER sees client’s password, which eliminates malicious system admin.
- But most apps prioritize speed over this last 0.1% of security improvement.
- For sensitive apps, like password manager (e.g., Bitwarden), client side hashing is used!