4 ms·
(Note: edited to make it more clear that hashing only on the client is insecure.) I think it is true that hashing on the client in addition to on the server of
by ykler 10y ago
(Note: edited to make it more clear that hashing only on the client is insecure.) I think it is true that hashing on the client in addition to on the server offers a little security boost since if someone is able to snoop a login, they will only see a hashed password, which they can use to compromise the user's account on the site being accessed but not on other sites where the user may use the same password (assuming you use a salted hash). Server hashing guards against the case where someone steals the database but not against the case where they snoop logins (and hashing only on the client wouldn't guard against this). Also, it might be practical to use more rounds of bcrypt on the client, but this is hard to say. Maybe you were downvoted, though, because you said server hashing is "effectively the same as storing the password in cleartext." Actually, the main win is probably from hashing on the server; the boost from also doing it on the client seems relatively minor.
- hvidgaard 10y agoIf we send the plaintext password we don't know that the server handles it responsibly. We don't know if they had to push an update under time constraint means that they now store passwords in plaintext. What we know is that we send plaintext password to the server on every login, that should, in a threat model, be considered as not using hashing at all. On the other hand, if the password is hashed client side, we KNOW that it cannot be stored as plaintext, because the server never knows it.
- temprature 10y agoYou're saying no one is doing password hashing right, from Google to Facebook to Apple to Microsoft to this very website we're posting on.
- hvidgaard 10y agoI'm not saying they're not doing it right... I'm saying that in a threat model there is a difference.
- JetSpiegel 10y agoIf you hash the password on the client, that hash IS the password. The attacker can just replay that request and can authenticate as you.
- hvidgaard 10y agoThat is not the issue we're protecting against, but preventing a leak from affecting other sites when the user is reusing a password.
- simcop2387 10y agoI've done this before in a site, probably badly. But the way I handled it is that on sign up I hashed the password on the client side and stored that once. Then during login as part of the form I also included a "challenge" (i suspect I was not rigorous with it) that went with it, so I had: HMAC(HASH(password), challenge), and that's what got sent across. Since the server had the original HASH(password) and the challenge it could verify that you knew the password without either the hash or password being sent. I know for a fact that I wasn't handling replay of the challenge properly but it wouldn't be too difficult to deal with it (add the time and have it expire after so long). But I definitely had other problems with it (no SSL, and probably bad sidechannel issues).
- hvidgaard 10y agoYes! You're the first in this thread that sounds like you have put actual throught into security and threat modeling.
- simcop2387 10y agoyea i think the bits i'd shoot for with this now are 1. Bcrypt(or scrypt, or similar) for initial hash of password. (used PBKDF2 i think before). 2. Add time expiration to the challenge-response 3. Rate limit the challenge/response per account 4. make sure to use a good hash for HMAC() (was using sha-1 since JS was much slower then). Ideally I'd also have a single challenge/response token per user and not let you get several to try against (i.e. invalidate old ones) but I'm not sure how I'd make that scale well. Maybe a salt+counter put into a hash (like HOTP) and then after a token is used invalidate all tokens with the counter less than the most recently attempted version?