Re:Digital Identity Guidelines: Public Comment Period
by ykler on Monday March 13, 2017 @06:22AM
(#13856562)
(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.
[ Parent
| on HN ]
Re:Digital Identity Guidelines: Public Comment Period
by hvidgaard on Monday March 13, 2017 @06:26AM
(#13856575)
If 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.
Re:Digital Identity Guidelines: Public Comment Period
by JetSpiegel on Monday March 13, 2017 @07:33AM
(#13856863)
If you hash the password on the client, that hash IS the password. The attacker can just replay that request and can authenticate as you.
Re:Digital Identity Guidelines: Public Comment Period
by hvidgaard on Monday March 13, 2017 @08:13AM
(#13857058)
That is not the issue we're protecting against, but preventing a leak from affecting other sites when the user is reusing a password.
Re:Digital Identity Guidelines: Public Comment Period
by simcop2387 on Monday March 13, 2017 @02:56PM
(#13861092)
I'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).
Re:Digital Identity Guidelines: Public Comment Period
by hvidgaard on Tuesday March 14, 2017 @04:40AM
(#13865962)
Yes! You're the first in this thread that sounds like you have put actual throught into security and threat modeling.
Re:Digital Identity Guidelines: Public Comment Period
by tripzilch on Saturday March 18, 2017 @04:39AM
(#13900473)
If we talk about "hash the password before sending to the server" this procedure is what we're talking about (or something similar). Surely people aren't thinking of literally just hashing the password and sending it on its merry way? If we say "symmetric encryption" we don't mean we're going to do AES(block_n, key) either (ECB mode should never be used for anything).
Re:Digital Identity Guidelines: Public Comment Period
by simcop2387 on Tuesday March 14, 2017 @01:04PM
(#13869307)
yea 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?
Re:Digital Identity Guidelines: Public Comment Period
by temprature on Monday March 13, 2017 @07:20AM
(#13856804)
You'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.