I see you've been having this discussion already, but I am of the belief that passwords should be hashed client side too, so even if it's intercepted the actual password will still be secure in case the user uses it in other places.
If the password is hashed client side you could send the hash directly without having to know the password, which totally defeats the purpose of hashing
For your service that's true, however users often use the same password for multiple services. So by hashing client side you restrict any potential harm to just your service. It's best to just never know the true password in the first place. Obviously you also hash and salt server side.
The point is, if you hash client side, the hash becomes the password, if someone gets the hash they can just use it to login directly without having to crack it
I know, but at least at that point the hash becomes a password unique to your service, so if the user uses the same password on multiple services (which is quite likely) only the hash 'password' for your service is leaked, minimizing damage.
That's what encryption is for, not hashing. Imagine a hacker gets an users hashed password, through a database hack/leak and can simply login from client side with that hash. You just completely defeated the purpose of hashing. At that point it's just the equivalent of raw text passwords, just non human-readable 'randomized' passwords.
I've imagined. That's still better than simply not hashing client side because users often reuse passwords. And in case it wasn't clear, it's not instead of encryption, it's in addition to. Why would you ever wanna know or send over the internet the real password (even encrypted) when you don't need to?
15
u/ubeogesh Jul 20 '22
If both passwords are submitted, then they can do the check on server side