4 ms·
Oh you mean the client sends 3 hashes and backend validates if just one matches?
by delaaxe 5y ago
Oh you mean the client sends 3 hashes and backend validates if just one matches?
- cylon13 5y agoHashing is done on the server. Hashing on the client would defeat the whole purpose.
- phailhaus 5y agoWhy? If you hash on the server, then you have to send the password in plaintext to the server. EDIT: Oh right, salts.
- cylon13 5y agoMore importantly if the server just accepts hashed passwords and stores them, then if you got ahold of a hashed password through a leak you could just use it directly to authenticate by modifying the client. The hashed password just becomes the password with one extra client-side step that you can trivially skip. Salting is more about making it non-obvious which passwords map to which hashes so you can’t easily build tables of hashes for common passwords. Sending the password to the server in “plain text” is fine over https, it’s a secure channel. Hashing isn’t meant to hide the password on the wire, it’s to prevent anyone with access to the database from learning what the passwords are.
- phailhaus 5y agoGreat point, thanks!
- jeltz 5y agoIf you do not want to send them in plain text you can use SCRAM.
- juloo 5y agoThe server could hash again the hashed password sent by the client. Especially if the client use an insecure hash algorithm (no secret salt for example). I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)
- nitrogen 5y agoThere are formalized approaches to keeping the server from knowing the password at any time: https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.m.wikipedia.org/wiki/Password-authenticated_key_a... SRP is one such system: https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
- staticassertion 5y agoThe various ZKP approaches are considerably more complex to implement properly vs the trivial approach of a client side hash. There are obvious tradeoffs, of course, but I wouldn't fault someone for an additional hash step on the client.
- Mogzol 5y agoHashing on the client still seems redundant though. In the end, whatever value is sent to the server is essentially plaintext, because it's all an attacker needs to know to authenticate. Whether it's the raw text the user typed or some transformed version of it isn't really relevant.
- naniwaduni 5y agoIn a world where password reuse is rampant, whether it's the raw text the user typed or a hard-to-reverse transformation on it is absolutely relevant to the user, just not to the service provider.
- freemint 5y agoThe client usually doesn't send hashes of passwords. Has he's are computed server side. Sending client side hashes beings no benefits
- naniwaduni 5y agoDouble-hashing (peppered on client, salted on server) does have a modest benefit: the passwords are no longer sent in plain-text and cannot be cheaply intercepted by a passive eavesdropper (i.e. without observably tinkering with the data sent). This often isn't considered worth the accessibility and maintenance costs of requiring the user to compute a hash (the threat model isn't exactly hugely concerning, especially to service providers, and is mostly obviated by transport encryption anyway) or the risk that somebody's going to come along and ask why we're hashing twice and rip out the server hash (very bad), but calling that "no benefits" is more or less lies-to-children.
- freemint 5y agoI've considered that but then there is transport encryption.