I’ve a question
do password get hashed on client send (web browser) or server-side within google account login?!
, if on server it’s disappointing we didn’t implement such a standard for web W3C so any <input type="password" must get hashed on client side and then send to any server, I need to understand this part.
1 Like
For Google specifically, the password is sent over HTTPS to Google’s servers where it’s hashed and verified. No client-side hashing happens in the browser before transmission.
Client-side hashing via W3C creates a security problem. If the browser hashes the password before sending it, the hash itself becomes the password. Anyone who intercepts or steals the hash can just replay it directly to the server without ever knowing the original plaintext.
There are some niche cases where client-side hashing is used as an extra layer, but it’s never a replacement for server-side hashing.
What’s the specific threat you’re thinking about? Like are you worried about HTTPS interception, or something else?
1 Like
From my experience building some websites and troubleshooting them as a support tech, all passwords are hashed on the Server side, meaning the password was sent to the Server in plain-text*.
I starred plain-text here because I want to be clear that the data you send to the Server vs the protocol used to transfer that data is different. The data you typed into the form is not hashed prior to transit. If the website has implemented HTTPS then the entire HTTP request was encrypted using TLS prior to being sent to the Server.
If the website is doing things properly, then they’ve likely done two things:
-
implemented HTTPS only for submitting sensitive data: This ensures that no one is snooping on the data between the Client and the Server (which is what makes MITMs so scary)
-
using POST requests. HTTP can send data from the Client to the Server through GET params (or query parameters) or through a POST Body. The params are what you see after the
?in a url, in key=value format. Those can be easily snooped. The POST Body is not as easily snooped and would require a MITM to gain access to that data (most web server apps don’t even facilitate logging the POST body for this very reason).
I would have to agree with @hydn here as I don’t believe that hashing on the client-side has a security gain, and most likely, I believe it has a higher security risk. Most password hashing today uses a hashing algorithm (like sha256 or sha512) AND a salt, a “prefix” to all hashes to help combat hash collisions (which are BAD) and create uniqueness even when the same value is hashed. If you knew the salt on the client-side, that would essentially reveal a way to precompute a bunch of hashes and bruteforce passwords much easier.
Hashing can also be compute-intensive and I would personally prefer to offload that compute-intensive work to the Server anyways and leave less responsibility on the Client.
1 Like