Hashing passwords client side has no benefit if a site uses HTTPS.
If a site uses HTTP, then hashing the password client-side and sending it up to the server is equivalent to sending a clear text password. If an attacker can already read your traffic, what is stopping them from using your password's hash to log-in to your account?
It stops them from using the password to log in to your other accounts.
It stops a compromised server from silently leaking unhashed passwords.
It makes password hashing user auditable.
You could even do a call and response model to stop the hashed password to log in at all. Here is a primitive scheme for such a model (public key crypto probably enables more clever schemes, not sure):
- Upon signup, generate hashes of "$password$site$i" for i in 1 to 1000. Send these to the server and have the server hash them again.
- Upon login, after the user has entered their password into the box, send an integer from i from 1 to 1000 to the browser, have the browser send back the hash of "$password$site$i".
Now a compromised hash can only let you log in 1 time in 1000. Combine that fact with the other available signals for "is this who we think it is" and you should be able to reject people who stole the hash reasonably reliably. Meanwhile since you are still hashing the password on the server (again) you have lost literally nothing but a tiny bit of computation time.
Use a password manager and don't reuse passwords. If your randomly generated, unique password has good enough entropy then why go through all of the trouble of the rest of the client side hashing?
There's nothing stopping you from hashing your own passwords client side and sending your bcrypt hash up to the server except some sites still truncate the passwords to 32/16 chars etc.
When you have the need for the level of security, client side hashing will not be as good as dedicated HSMs that many services now use on authentication.
Writing your own crypto flows can be extremely dangerous as you open yourself to all kinds of side channel attacks.
A password manager is a client side method that only works for people who opt into it, Google needs to deploy a server side method. Likewise with hashing my own passwords client side. HSMs.
As for writing my own crypto. Indeed, if anyone actually used the scheme I suggested they would be making a mistake. I wrote it not to be used but to demonstrate that we can do better in an easy to understand way. Unlike me, Google has the resources to read the papers, do the math, carefully implement this, and do it properly.
Keywords for how to do it properly include "zero knowledge password proof" and "password authenticate key exchange".
PS. It's irrelevant to this conversation, but putting all my passwords into one program has always struck me as a monumentally stupid idea. I use one for passwords I don't care about, I memorize unique passwords for passwords I do care about.
worshipping an arbitrarily contrived measure of password entropy makes for good security theatre, but there's a lot that goes into maintaining anything resembling actual security. How many people use "password generators" and trust that they'll come up with "random" words? What about that old saying about putting eggs in a basket?
> It stops a compromised server from silently leaking unhashed passwords
If you trust the site to deploy correct JavaScript to do this, then that's the same level of trust that they implemented password salting and hashing server side. You don't gain any robustness by moving this to JavaScript.
Your scheme is just a weak salting technique. You'd be better off with just using a longer salt and hash function.
> - That is auditable - it is impossible for a malicious site to do so without risking being caught.
Hardly. Minimization and obfuscation is trivial, and you can ensure the output is always different in order to defeat auditing. Not great for caching obviously, but 'auditability' is not achievable if the server is determined to fool you.
> - The HTML/JS can be served from static cloud storage that is far less likely to be hacked than the server running a DB verifying passwords.
Password are simply not where you want to leverage your security. If you can find a document example of a real threat that this approach would have mitigated, then I'll take it seriously.
This is completely wrong. HTTPS is what secures this, not client side password hashing. If you don't use HTTPS, you can just get MITM'd to disable any kind of client side hashing.
You are wrong. Client-side hashing CAN be a silly thing, but it can also prevent a (compromised) server from seeing your password which you probably use on other websites (which is what most people do unfortunately).
>but it can also prevent a (compromised) server from seeing your password
If the server is compromised, then there is no protection of your cleartext password at all. This is because the entity that compromised the server can replace the original JS with anything, including new JS that sends your cleartext password off to their own host as you type each character.
The only activity on your part that can save you against comprimised servers is having a unique password per server (i.e., not reusing any passwords).
Not true in modern architectures, that situation only applies to more traditional file & api server combo's. If you statically serve your site with a service like s3 and have a backend running on lambda or ec2 - the attacker cannot modify the static assets and the client side hashing will prevent them from seeing the plaintext password.
The answer is that it depends. We could be talking about protected js with SRI, signed updates with an electron client, a browser plugin or native hashing, a protocol similar to SSH that hashes the client pw, etc.
This is only true when client-side hashing is under control of the client. In a web browser, it is not. The browser will happily run whatever JS the server sends it. So if the server is compromised, it can send compromised JS, and there goes your client-side hashing protections.
An example of where it might work is in an app, where you're getting the client code from a separate channel like an app store.
It can protect you against non-malicious issues on server-side. If I recall correctly, twitter recently discovered that they were logging passwords in plaintext by accident. With hashed password you reduce exposure of actual passwords in this type of situation.
If a site uses HTTP, then hashing the password client-side and sending it up to the server is equivalent to sending a clear text password. If an attacker can already read your traffic, what is stopping them from using your password's hash to log-in to your account?