[wongarsu]

There are various schemes where the password is salted, hashed or prehashed on the client side, to various effectiveness. They have never been really popular and the advent of ubiquitous https probably made them even less common, but they do exist. They do help protect you from your own WAF though.

[d-z-m]

can you elaborate on this? Or link something that does? My intuition is that whatever gets sent over the wire is effectively the password. Not sure how the server could validate some rolling hash of the password (based on like a timestamp or something) without having to store the pre-image(i.e. the raw password).

[liversage]

The SRP Authentication and Key Exchange System does not send the password from the client to the server. This scheme is supposedly used by Blizzard when authenticating users in some of their online games.

https://www.rfc-editor.org/rfc/rfc2945

https://security.stackexchange.com/questions/18461/how-secur...

[wongarsu]

Yes, that's the common counter argument. Your hash has now just become the password, and no amount of clever salting really solves that.

It still prevents the server (and any proxies, MitM attackers, etc) from seeing the plain-text password, which can help protect the user if they reused the password somewhere else. Assuming the client wasn't also compromised, which is very likely in web applications but maybe a valid scenario in apps and desktop applications.

The other imho valid idea is that you can run a key derivation function client-side (e.g. salted with the user-name), in addition to running your normal best-practice setup server side. This can allow you to run more expensive key derivation which provides more protection if your database is leaked, while also making dictionary attacks on your authentication endpoints less viable.

[aidenn0]

If your password is 123456, then client-side hashing will make this less obvious. If the site is compromised in a way that reveals passwords, then it will not trivially work on other sites that use your password. In addition, stronger total hashing can be used, since if your server can do M hashes persecond and your client can do N hashes per second, the total number of hashes to allow a one second login are (M/$NUMBER_OF_CONCURRENT_LOGINS)+N which is strictly larger than (M/$NUMBER_OF_CONCURRENT_LOGINS).

SRP[1] is an even better improvement, where an eavesdropper cannot authenticate as you; there is a challenge-response to login.

1: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...