5 ms·
If you hash in the client, attackers with dumped hashed credentials (from elsewhere, which might only hash plaintext) don't need to try to reverse/"crack" the h
by 0x0 6y ago
If you hash in the client, attackers with dumped hashed credentials (from elsewhere, which might only hash plaintext) don't need to try to reverse/"crack" the hashes, they can just use them as-is. With users reusing passwords across sites, that would be pretty terrible.
- devado 6y agoI think the idea is to hash on client _and_ the server. The client 1-way hash (~~unlike the server's 2-way~~) is the new "password" now and it's sole purpose is so that you don't get to see the raw password on the server.
- triou 6y agoThat is why he said, we should do both: hashing client AND server side. Hashing on the client prevents sending plain text passwords to the server which could mishandle them eg. Logging them for instance like Twitter once did. Client side you can also check on registration if the user password is known to have been pwned (1password offers an api for that) and use a secure hashing algorithm. Server side the hash (which is then the password) will be salted and hashed again.
- arghwhat 6y agoNo - As mentioned in a comment elsewhere, these kinds of experiments fall dangerously into a category of duct-tape crypto. If you want secure password transfer, do not construct a ghetto solution with stacked hashes, but use a proper protocol like SRP (which, again, is pointless unless the client is trusted). Especially in the case of Twitter, doing this provides absolutely nothing in respect to credential confidentiality as both sites of the transaction is written by Twitter.
- mafuy 6y agoI don't get it. Assuming that a passivly listening attacker has broken TLS, additionally hashing at the client is helpful. The service at hand is now (most likely) insecure, but at least other services do not suffer from the plaintext password being exposed. It's an advantage, albeit small, but it's easy to do with virtually no risk of error.
- 0x0 6y agoIf TLS is broken, the world has bigger problems. And then they could simply intercept the session cookie either way.
- ryukafalz 6y agoThe session cookie isn’t a potentially reused human-readable string though. The password is.
- arghwhat 6y agoIf TLS was broken, I would always be able to get your password by just removing the hashing from the login page. I'd also be able to modify all legitimate requests, and be able to obtain your genuine login tokens for any site.
- ryukafalz 6y agoThat requires an active attack though. Yes, that’s always possible if TLS is broken, but it takes more work and is detectable. (Not saying it’s easy to detect, but it’s detectable in theory, where passive sniffing is not.)
- 0x0 6y agoThat makes the hash of the user's password equivalent to a plain text password. And that means all those leaked databases, which previously only contained hashes that needed to be bruteforced to be reversed, suddenly function as a source of plaintexts.
- Dylan16807 6y agoNo. The database only contains the double hash. It still needs to be bruteforced. There is zero downside to doing an extra hash, except the chance that someone codes such a basic thing wrong.
- 0x0 6y agoNo. Other websites on the internet, where the user also registered with the same email and password, contain the single hash.
- Dylan16807 6y agoOh, I see. Other websites give you the 'password' to this website. But only if neither site uses salt, so salt all your hashes. (Not even a salt is necessary here, just a site-wide addition would be fine. Or honestly you could just use a hash that wouldn't be used by a site too dumb to salt their database.)
- evanreichard 6y agoI think (s)he is saying to hash client side, salt, then hash again server side. So if the database gets compromised, the attacker still has to apply the salt to brute force the hash. I can't see a reason why this hurts, but it's probably not worth it. The only benefit I can see it having is if the user reuses their passwords on other sites, as now a potential malicious MITM would have to brute force the client side hashed password in order to reuse it on other sites. They would still be able to use that client side hashed PW to authenticate to the service in question, though.
- 6y ago
- em-bee 6y agonotwithstanding all the other caveats mentioned here, wouldn't hashing on the client side make it possible to salt the hash so that different sites generate a different hash, thus making it unlikely that the hash can be reused even if the actual password is the same? the salt could even include a time component making the hash expire after a time. this obviously does not eliminate the need for other security measures, so it's possibly more a question of "is it worth it?"