6 ms·
So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to
by ams6110 9y ago
So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?
- jrochkind1 9y agonah, that just makes the "hashed password" the equivalent of the cleartext password. Whatever it is your client sends to the server for auth is the thing that needs to be protected. If the client sends a "hashed password", that's just... the password. Which now needs to be protected. Since if someone has it, they can just send it to the server for auth. But you can do fancy cryptographic things where the server never sees the password and it's still secure. like the entire field of public key cryptography, diffie-hellman key exchange, etc.
- ams6110 9y agoMakes sense, and then you're getting into something akin to SSH key pairs, and I know from experience that many users can't manage that especially across multiple client devices.
- jrochkind1 9y agoThere are probably ways to make it reasonable UX, but they probably require built-in browser (or other client) support. Someone in another part of this thread mentioned the "Web Authentication API" for browsers, which I'm not familiar with, but is possibly trying to approach this?
- tehbeard 9y agoWeb Auth API (authn) does try to make it usable. It ties in with the credential management API (A way to have the browser store login credentials for a site, a much less heuristic based approach than autocomplete on forms) and basic principle is generate a key pair, pass back public key to be sent to server during registration. On login generate a challenge value for the client to sign. I don't think iirc the JS code ever sees the private key, only the browser sees it.
- kevin_thibedeau 9y agoUseless unless browsers get their act together and encrypt their autocomplete data. I would never trust any API loosely associated with it.
- jrochkind1 9y agoHow does Web Auth API and Credentials Management API address the "manage across multiple client devices" issue?
- hunter2_ 9y ago"Since if someone has it, they can just send it to the server for auth" unless it's only good for a few moments (the form you type it into constantly polling for a new nonce).
- jimktrains2 9y agoOr you could just use PAKE or SRP.
- deepbreath 9y agoThe server would not be able to verify a changing hash without knowing the password
- jchw 9y agoI believe you could use a construction like HMAC to make it so that during authentication (not password setting events) you don't actually send the token. But if someone is already able to MITM your requests, what are the odds they can't just poison the JavaScript to send it in plaintext back to them?
- tripletao 9y agoI think their goal is to still use https, but stop anything important from leaking if a sloppy server-side developer logs the full requests after TLS decryption (as Twitter did here).
- theon144 9y agoBut wouldn't you due to random salting at least mitigate the disclosure of the password which might people use elsewhere? edit: considering someone eavesdrops on the connection, otherwise that's a whole different kind of vulnerability
- hiccuphippo 9y agoBut then you have to store the password instead of a hash of it because it would change each time thanks to the salt. A much worse situation.
- jaccarmac 9y agoYou can store things as follows. Store the salted hashed password with its salt server side. When the user wants to login send them the salt and a random salt. Client side hashes the password + salt then hashes that hash with the random value. What am I missing? Probably something since this is something I rolled my own version of when I was a teenager, but it's not immediately obvious to me.
- deepbreath 9y agoIt's unclear to me how your random salt would work. From my understanding, you're suggesting smth like: register: send (username, user_salt, HMAC(user_salt, pwd)) login: send (username). retrieve user_salt. retrieve a server_salt generated randomly. send HMAC(server_salt, HMAC(user_salt, pwd)) But now your password is effectively just HMAC(user_salt, pwd), and the server has to store it in plaintext to be able to verify. Since plaintext passwords in the db are bad, this solution doesn't sound too attractive, unless you were suggesting something else.
- jaccarmac 9y agoNope, that's what I was suggesting and I see now where it's weak.
- brownell 9y ago
- mehrdadn 9y agoNot really... it's not that simple. You could use the time of day as a seed for the hash, for example. There are tradeoffs to be made, which is partly why they don't do it, but the story isn't as simple as "the hash becomes the password".
- euyyn 9y agoThen how does the server check that it's valid?
- mehrdadn 9y agoThe time of day is known to both the client and the server right? So they check to see that they get the same hash.
- deepbreath 9y agoBut the password is only known to the client?
- mehrdadn 9y agoOnly if the server only keeps around the hash -- which is why I said there are trade-offs to be made. The point I was making was that the mere fact that you're sending a hash does not trigger the "hash-becomes-password" issue; that's a result of secondary constraints imposed on the problem.
- hermitdev 9y agoAnd how do you propose to do that when the clocks arent synchronized? Clock drift is exceptionally common. Not everyone runs ntp or ptp. Probably even fewer use ptp. Desktop/laptop clients it's typically configurable on whether or not to attempt clock sync, and ive never seen where the level of synchronization is documented for PCs. High precision ptp usually requires very expensive hardware, not something to be expected of home users or even a startup depending on the industry.
- earenndil 9y agoCouldn't you hash it client-side, then hash it again server-side?
- honoredb 9y agoNo, there fundamentally isn't, because you can't trust the client to actually be hashing a password. If all the server sees is a hash, the hash effectively is the password. If it's stolen, a hacker can alter their client to send the stolen hash to the server.
- iGoog 9y agoIf a hash is salted with a domain it won't be use-able on other websites. You should additionally hash the hash on the server, and if you store the client hashes, you can update the salts on next-sign in. A better question is why clients should be sending unhashed passwords to servers in the first place. https://medium.com/the-coming-golden-age/internet-www-security-vulnerability-rfc-54a23b1ea113 https://medium.com/the-coming-golden-age/internet-www-securi...
- Tarean 9y agoThis discussion is only relevant with an attacker that can break tls. A hash that such an attacker couldn't reverse might be slow on old phones so there is a tradeoff. Also, hashed passwords shouldn't be logged either.
- deleted 9y ago[deleted]
- dec0dedab0de 9y agoYou could do client ssl certs and just skip the password. It would be more work for the user though.
- cabaalis 9y agoThat would transfer it from something you know (a password) to something you have (a device with SSL cert installed) which are meant to protect against different problems.
- krapp 9y ago>That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that? No [0,1...n]. Note that these articles are about encryption, but the arguments against javascript encryption apply to hashing as well. Also consider that no one logs this stuff accidentally to begin with. If the entity controlling the server and writing the code wants to log the passwords, they can rewrite their own javascript just as well as they can whatever is on the backend. There's nothing to be done about people undermining their own code. [0]https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... [1]https://tonyarcieri.com/whats-wrong-with-webcrypto https://tonyarcieri.com/whats-wrong-with-webcrypto
- deleted 9y ago[deleted]
- adrianmonk 9y ago> consider that no one logs this stuff accidentally to begin with It's possible. You create an object called Foo (possibly a serialized data like a protobuf, but any object), and you recursively dump the whole thing to the debug log. Then you realize, oh, when I access a Foo, sometimes I need this one field out of the User object (like their first name), so I'll just add a copy of User within Foo. You don't consider that the User object also contains the password as one of its members. Boom, you are now accidentally logging passwords.
- johnsonjo 9y agoAny user object on the server should only ever have the password when it is going through the process of setting or checking the password, and this should be coming from the client and not stored. So, your case of logging the user would only be bad at one of those times. Otherwise like in the case of a stored user you should just have a hashed password and a salt in the user object.
- krapp 9y agoOk. Creating a User object that holds a password (much less a password in plaintext) seems next level stupid to begin with, but fair enough, I guess it could happen.
- deleted 9y ago[deleted]
- tylersmith 9y agoAs others have stated, you'd just be changing the secret from <password> to H(<password>). The better solution is using asymmetric cryptography to perform a challenge-response test. E.g. the user sets a public key on sign up and to login they must decrypt a nonce encrypted to them.
- ryanmcm 9y agohttps://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
- hiccuphippo 9y agoInstead of trying to hash the password, just use SSL so the whole request is encrypted. But that doesn't fix servers accidentally logging passwords. Maybe there could be a standard way to signal the beginning and end of a password string so logging software can redact that part.