> found Meta to have inadvertently stored certain passwords of social media users on its internal systems without encryption, and fined it €91m (£75m)
WTF? I thought that on 2010 already people were diligent enough to avoid even sending the password and instead just hashed it locally before even sending it.
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)
There'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.
i 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.
WTF? I thought that on 2010 already people were diligent enough to avoid even sending the password and instead just hashed it locally before even sending it.