5 ms·

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 othe

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).

amaccuish 8y ago
and if said "compromised" server simply decides to not supply the js that hashes the password?
- naasking 8y ago
  Thanks for saying it. Client-side scripting can't protect against a compromised server when the client scripts are provided by that same server.
- the_clarence 8y ago
  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.
- deleted 8y ago
  [deleted]
pwg 8y ago
>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).
- brod 8y ago
  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_clarence 8y ago
  Again, this is wrong depending on how the client is implemented, if updates are signed, if we are talking about a protocol, etc.
skunkworker 8y ago
This is why server side HSMs (hardware security modules) are a thing.
snowwrestler 8y ago
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.
- brod 8y ago
  or a separate channel like another server - which is the standard in every large web application I've ever seen.
- Isinlor 8y ago
  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.

amaccuish 8y ago

and if said "compromised" server simply decides to not supply the js that hashes the password?

naasking 8y ago
Thanks for saying it. Client-side scripting can't protect against a compromised server when the client scripts are provided by that same server.
the_clarence 8y ago
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.
deleted 8y ago
[deleted]

pwg 8y ago

>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).

brod 8y ago
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_clarence 8y ago
Again, this is wrong depending on how the client is implemented, if updates are signed, if we are talking about a protocol, etc.

skunkworker 8y ago

This is why server side HSMs (hardware security modules) are a thing.

snowwrestler 8y ago

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.

brod 8y ago
or a separate channel like another server - which is the standard in every large web application I've ever seen.
Isinlor 8y ago
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.