3 ms·
That is not standard even today. The main threat is in transit over the network, which https/TLS solves, but obviously this won’t stop error traces or logging o
by varun_ch 6mo ago
That is not standard even today. The main threat is in transit over the network, which https/TLS solves, but obviously this won’t stop error traces or logging on the server from including request bodies.
If you do hash locally (not sure I’ve seen any big players do this), you also need to be hashing server side (or else the hash is basically a plain text password in the database!)
That said, I’m not sure why companies don’t adopt this double hashing approach. Complexity maybe? I know it could limit flexibility a little as some services like to be able to automatically attempt capitalization variations (eg. caps lock inverse) on the server. Anyways in 2026 we should all be using passkeys (if they weren’t so confusing to end-users, and so non-portable)
- em-bee 6mo agoif you hash locally isn't that effectively like using private/public keys but less secure? might as well use the real thing then.
- dietr1ch 6mo agoThere's no effectively using private/public keys whatsoever. The communication with the server must be secure, the extra hash only provides the ability for the server's data getting leaked without compromising the password through server logs. The usual setup I'd say is to salt the password in the server and store (salt, hash(pw+salt)), but that still handles text-plain password that might get logged by mistake.
- em-bee 6mo agoi meant in term of complexity, if i hash the key on the client, but don't want the hash to become the password then i have to do some dance with sharing a secret or something that is as or more complex than using private/public keys outright.