5 ms·

That 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 mi

by triou 6y ago

That 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 ago
No - 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 ago
  I 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 ago
    If TLS is broken, the world has bigger problems. And then they could simply intercept the session cookie either way.
    - ryukafalz 6y ago
      The session cookie isn’t a potentially reused human-readable string though. The password is.
      - arghwhat 6y ago
        If 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 ago
        That 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.)
        arghwhat 6y ago
        If TLS is broken, you lose all message authentication, rendering tampering entirely undetectable. Passive sniffing requires the same attack vector, and the idea of an attacker only utilizing passive attacks makes no sense. The point is that additional hashing designed for the premise of "broken TLS" fails the thread model test: It is pointless, as the only time it is applicable is when everything is fallen apart.
    - Dylan16807 6y ago
      TLS itself doesn't have to be broken to have an interceptor.
      - 0x0 6y ago
        If your machine has TLS being intercepted nothing matters anymore. That would be the equivalent of having a keylogger installed. There's no point in trying to protect such a client anymore, it's game over then.
        Dylan16807 6y ago
        Passive interception happens. Especially when you're using a cipher that isn't forward-secure; a breach of the server could allow it to decrypt previous sessions.
  - arghwhat 6y ago
    Stacking hashes is not cryptographically sound. The additional hashing weakens the credentials. Cryptographic hashing is a very fragile subject. "Assuming an attacker has broken TLS" - this makes no sense. If I had broken TLS, I could send you a login form with no hashing. I could modify your legitimate API requests, without the need for your credentials. I could take your token and forge requests as I wanted. All your assumptions go down the drain, as the security relied on the presence of TLS. Basically, making this setup is generally harmful, while only providing negligible benefit in a doomsday scenario where all bets are off regardless. If you truly want to have better security, you need an entirely different system. E.g., local private keys used to sign requests, or a proper password exchange/validation protocol. Smacking another hash on top does nothing good, and the idea is a good example of why normal people shouldn't crypto.
    - Jach 6y ago
      I've heard the "additional hashing weakens the credentials" line since I started programming, but no one ever bothers to link a citation, or if just reasoning simply from e.g. the pigeonhole principle seems to realize the increased likelihood of collisions is negligible for typical hash choices. It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client. I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...
      - arghwhat 6y ago
        > I've heard the "additional hashing weakens the credentials" line since I started programming, but no one ever bothers to link a citation The main issue is that security analysis is non-trivial due to the interaction of their security guarantees. The end-result is effectively a new hashing algorithm. Figuring out the properties of this new algorithm requires a new cryptoanalysis (which is more than just avalanche tests). > It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client. Old practices are deprecated for good reason, primarily due to flaws. Looking at what we used to do it not that useful. The main problem is that it's not just "n rounds". The hash on the client must be salted, and it must be salted uniquely for that credential set, and must use a different salt from the backend hash. Plenty of ways to mess this up, and that's before we're even consider the implementation details of salting. Then comes the interactions between likely different hashes. All in all, it's pretty complicated. > I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords... Especially with the only sensible procedure being password managers, it's silly we don't have asymmetric authentication. :(
  - mafuy 6y ago
    I'd like to highlight that "passively listening" was written intentionally. As soon as an attacker becomes active, he's at an incomparably higher risk of being detected.
0x0 6y ago
That 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 ago
  No. 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 ago
    No. Other websites on the internet, where the user also registered with the same email and password, contain the single hash.
    - Dylan16807 6y ago
      Oh, 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 ago
  I 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

by triou 6y ago

arghwhat 6y ago

No - 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 ago
I 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 ago
  If TLS is broken, the world has bigger problems. And then they could simply intercept the session cookie either way.
  - ryukafalz 6y ago
    The session cookie isn’t a potentially reused human-readable string though. The password is.
    - arghwhat 6y ago
      If 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 ago
        That 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.)
        arghwhat 6y ago
        If TLS is broken, you lose all message authentication, rendering tampering entirely undetectable. Passive sniffing requires the same attack vector, and the idea of an attacker only utilizing passive attacks makes no sense. The point is that additional hashing designed for the premise of "broken TLS" fails the thread model test: It is pointless, as the only time it is applicable is when everything is fallen apart.
  - Dylan16807 6y ago
    TLS itself doesn't have to be broken to have an interceptor.
    - 0x0 6y ago
      If your machine has TLS being intercepted nothing matters anymore. That would be the equivalent of having a keylogger installed. There's no point in trying to protect such a client anymore, it's game over then.
      - Dylan16807 6y ago
        Passive interception happens. Especially when you're using a cipher that isn't forward-secure; a breach of the server could allow it to decrypt previous sessions.
- arghwhat 6y ago
  Stacking hashes is not cryptographically sound. The additional hashing weakens the credentials. Cryptographic hashing is a very fragile subject. "Assuming an attacker has broken TLS" - this makes no sense. If I had broken TLS, I could send you a login form with no hashing. I could modify your legitimate API requests, without the need for your credentials. I could take your token and forge requests as I wanted. All your assumptions go down the drain, as the security relied on the presence of TLS. Basically, making this setup is generally harmful, while only providing negligible benefit in a doomsday scenario where all bets are off regardless. If you truly want to have better security, you need an entirely different system. E.g., local private keys used to sign requests, or a proper password exchange/validation protocol. Smacking another hash on top does nothing good, and the idea is a good example of why normal people shouldn't crypto.
  - Jach 6y ago
    I've heard the "additional hashing weakens the credentials" line since I started programming, but no one ever bothers to link a citation, or if just reasoning simply from e.g. the pigeonhole principle seems to realize the increased likelihood of collisions is negligible for typical hash choices. It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client. I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...
    - arghwhat 6y ago
      > I've heard the "additional hashing weakens the credentials" line since I started programming, but no one ever bothers to link a citation The main issue is that security analysis is non-trivial due to the interaction of their security guarantees. The end-result is effectively a new hashing algorithm. Figuring out the properties of this new algorithm requires a new cryptoanalysis (which is more than just avalanche tests). > It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client. Old practices are deprecated for good reason, primarily due to flaws. Looking at what we used to do it not that useful. The main problem is that it's not just "n rounds". The hash on the client must be salted, and it must be salted uniquely for that credential set, and must use a different salt from the backend hash. Plenty of ways to mess this up, and that's before we're even consider the implementation details of salting. Then comes the interactions between likely different hashes. All in all, it's pretty complicated. > I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords... Especially with the only sensible procedure being password managers, it's silly we don't have asymmetric authentication. :(
- mafuy 6y ago
  I'd like to highlight that "passively listening" was written intentionally. As soon as an attacker becomes active, he's at an incomparably higher risk of being detected.

0x0 6y ago

That 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 ago
No. 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 ago
  No. Other websites on the internet, where the user also registered with the same email and password, contain the single hash.
  - Dylan16807 6y ago
    Oh, 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 ago
I 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