For websites, is your password's hash computed on the client or the server side?

I was wondering if passwords' inputs are "converted" locally on the client/web browser side or on the server side.

Usually (with regular forms-based logins) everything is done on the server side.

but in that case it brings a concern to me: that means you are sending your password to a third party. Indeed the password will travel in a secure channel to the server, but in the end the server could do whatever it wants with it

Yes it could. Hence the admonitions against password reuse.

Computing the hash yourself and sending it to the server would make the authentication process so much more secure.

On its own – no, it won't. It'll trade one risk for another.

With server-side hashing, if the server's database leaks (which happens a lot more often than TLS MITM), those hashes are mostly useless unless cracked one by one. With client-side hashing, the attacker could simply start sending those hashes like they were passwords! Instead of a one-time DB leak, now the attacker can log in to everyone's accounts, and they can keep those hashes to themselves and use them to log in months or years later.

(If you made both sides (first client, then server) hash the passwords, this still wouldn't stop a malicious server from storing the client-sent hashes and re-sending them somewhere else, again like passwords.)

To actually avoid both issues, you'd need more than just hashing; you'd need a slightly more complex protocol (e.g. some kind of challenge/response that isn't completely misdesigned like "HTTP Digest" was). You'd also want to ensure that the hash sent by the client cannot be reused at a later time (or even on a different site), as "replay attacks" are an issue with many protocols.

For example, the SCRAM protocol is now somewhat common among non-web systems such as PostgreSQL or MongoDB. However, to a web developer, all of those are significantly more complex than just making an HTML <form> – they require custom JavaScript code, and they often require multi-step interaction with the server.

It seems that "since we're adding JavaScript anyway", the web in general is moving towards protocols that don't involve passwords at all, such as WebAuthn which works with public-key signatures (a bit like SSH). This doesn't necessarily mean hardware dongles and 2FA – "Windows Hello PIN" is one example of WebAuthn provided by the OS.

Computing the hash yourself and sending it to the server would make the authentication process so much more secure

No, accepting hashes instead of passwords would make the process much less secure. It would be the same as keeping plain-text passwords: if an attacker steals the server database containing usernames and hashes, they could instantly login as any user!

The whole purpose of hashing is to force attackers to reverse a one-way function: computing a hash from a know password is trivial, finding passwords matching a given hash is hard. Poor passwords like dictionary words are compromised when hashes are stolen, because computing hashes over 100'000 words is fast. Good passwords remain secure, because to compute the hash you need to guess the password first.

Yes, when you enter a password in a website, it is transmitted to the server in plain text, and the script on the server can then do anything with it, even store it in plain text as well. In order to protect users (websites are required by law in most countries), they hash the password and store the hash only, but that doesn't mean it always happens.

But even so, if a password hash is hacked, it could eventually be reversed to a plain password if really wanted and enough time is at hand (given they also get the security hash).

So what does this mean, always use unique passwords on every site. It is best to use a password manager that comes with a random password generator so you can just remember one password and forget about the rest. There are cloud based solutions but also local solutions depending on how much you distrust cloud computing.

As for the computing the hash locally, technically it is possible to do this with javascript but it brings a huge security risk. When you create a password hash, you use a unique hash (security hash) that the hash eventually is based upon. Because this unique hash is not known locally, it is not possible to decrypt the password. If you do local hashing, then suddenly the server must first send you the secret security hash to get the hashed password. A hacker could then easily decrypt any hash.

The password has to be hashed on the server side. If you hash the password on the client on the server side and send the hashed password to the server, then the hashed password is the thing the server checks to authenticate you, and "thing the server checks to authenticate you" is, by definition, the password. So by definition, the thing you send the server is the password. If the thing you send is generated by hashing something, then you're doing a bunch of extra work for no reason. More importantly, the replacing your password with the hash of your password server-side is useless, since it does nothing to change the threat vector of "if someone hacks into the server, they'll have data that will let them log into your account". The whole point is for the server to not have information that will allows authentication; authentication requires both your secret information (your password) and their secret information (what your password hashes to).

Indeed the password will travel in a secure channel to the server, but in the end the server could do whatever it wants with it.

Ummm... yeah? It's not like it's possible to create a security system that protects against the threat vector of "The people running the server are doing things they shouldn't be doing."

Computing the hash yourself and sending it to the server would make the authentication process so much more secure.

No, because, as I explained, that would mean that you're sending what is effectively your password. That is, you are sending something that, if intercepted, would allow free access to your account. Neither sending the hashed version nor sending the unhashed version addresses that threat vector. Either way, anyone who can read the traffic can impersonate you.

To address this vector, you'd need further security protocols, such as having the communication be over an encrypted channel, and requiring all messages to include a randomly generated salt that changes from session to session.