7 ms·

> So passwords do get I think you meant "don't get" Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the

> So passwords do get I think you meant "don't get" Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. There are protocols like SRP to do it securely, but it's non-trivial. And remember that such protocol is only useful if you trust the client implementation—it's kind of pointless for a third-party webpage or app. Use randomized per-site password. Solves everything.

jialutu 6y ago
Thanks, corrected :)
gpm 6y ago
> Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. I've yet to see someone give a good reason to not hash on the client and the server... I would be curious to hear if you have any. It's definitely non-standard though.
- Zimahl 6y ago
  Isn't the main security feature of hashing that you hash against a salt and that no one but the server knows the salt? Once you send the salt to the client (and anything on the client should be considered insecure) you give the ability to generate lookup tables for common passwords. Without the salt it's much harder to brute-force the password.
  - fhars 6y ago
    No, the salt can be public (it was on Unix machines before the invention of /etc/shadow). The important thing is that it is unique per password, so that Hash(Salt#Password) is unique even if two passwords happen to be the same.
  - nikisweeting 6y ago
    Just use a different salt on the client and server. (and potentially even a different salt for each client)
  - UncleMeat 6y ago
    No. Salts are not intended to be secrets. The expectation is that in the case of a breach that salts are also exposed. What they do is prevent precomputation of lookup tables, granting the developer a bit of time after a breach before all bets are off.
- 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 ago
    I 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.
    - ht85 6y ago
      > server's 2-way Are thinking of encoding / decoding? If so it isn't used for passwords.
      - devado 6y ago
        indeed, scratch that. i rewrote that comment a couple of times, and that 2-way part is of course not correct. this would defeat the point of hashing passwords if they were reversible
  - 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.
- mneubrand 6y ago
  You can't enforce complexity rules or check against known leaked passwords or that they don't reuse username as password or anything like that if you hash on the client too
  - ALittleLight 6y ago
    You can check complexity or username reuse client side. You could even block the n most common passwords clientside if you wanted to.
    - phab 6y ago
      But I could just ignore/comprimise/modify your client and submit whatever I liked to the server.
      - smolder 6y ago
        What's the motivation of someone able to do that and interested in doing it?
        SiNiquity 6y ago
        Primarily to get around arbitrary password rules that do not enhance the security of the password but serve to weaken it, e.g. only use special characters from this list: !@#, or sorry your password is TOO LONG (?!)
      - labawi 6y ago
        That's true, but only to a point. You can actually server-side check username/password equality, and a not overly long list of other unwanted passwords. You just have to check each one.
- progre 6y ago
  Wouldn't hashing on the client side possibly introduce a reduction in complexity of the password? The hashed password on the client side could be used in place of the plaintext password if the channel is insecure. Lets say the password length limit is 256 ascii chars this is 8*256 bits (ok a little less since not all ascii chars are printable), but if hashed on the client (lets be generous and hash to 1024 bits) it's still half the complexity of the plaintext.
  - ALittleLight 6y ago
    I'm not understanding this. Couldn't you choose an arbitrary amount of bits to hash to on the client side?
  - smolder 6y ago
    It's less about bits and more about entropy. Passwords tend to be low on entropy because of words and patterns present in the sequence. Its almost always going to be harder to break passwords by trying every possible hash than doing dictionary attacks against plaintext passwords. 256 bits is around 37 characters of base64 text. Compare that to most passwords and it's safe to say they aren't losing entropy when hashed.
  - johannes1234321 6y ago
    If you are not including humans your maths might be right. With humans not all 8 bits of extended ASCII are realistically used in passwords. And rarely you get passwords longer than 10 characters. And then: By the password not leaving the system you avoid another issue with humans: If the hash is lost (accidental logging and locks leaking and such things happen) this won't allow to sign in to other accounts, where the lazy human used the same password. For machine-to-machine communication tokens with higher entropy can and should be used.
  - gpm 6y ago
    A 128 bit random plaintext is more than secure enough... If you're trying to argue that the user puts in, say, 60 bits of entropy, and that the hashing algorithm is going to accidentally throw out 10 of those to result in 50 bits of entropy, I believe that any hashing algorithm that did that in a way that anyone can exploit with realistic computing power (a computer smaller than the size of the solar system) would be considered irredeemably broken.
- arghwhat 6y ago
  1. If the client is written by the same people as the server, then it provides no improvement in password confidentiality. 2. It provides no additional security in the authentication process. 3. It provides no additional security-at-rest for post-breach protection. Doing something like that ends up in the dangerous bucket of duct-tape crypto. I don't mind people playing with crypto, but things are not as simple as they seem, and "more" is not necessarily better.
  - SiNiquity 6y ago
    The client in this case should be the web-browser; it shouldn't be custom Javascript. There should be an attribute on the password field that says if the password should be hashed before sent to the server. It could also be salted by the browser to reduce reuse across sites similar to any password manager today.
- smolder 6y ago
  Hashing twice, on the client as well as on the server, won't introduce any security issues if the choice of algorithm is good, and it does further protect the users password from being harvested from passive MITM'd SSL like it is on some corporate networks. (Yes I know MITM means they could rewrite the client to steal passwords, but that's work) If I was designing a password auth scheme that highly prioritized user security, I would hash both client and server side.
  - Sir_Substance 6y ago
    >and it does further protect the users password from being harvested from passive MITM'd SSL like it is on some corporate networks. It might protect the password if the user is reusing it elsewhere, but it doesn't protect the account the password is securing during the intercepted transmission. The MITM attacker can just replay the hash.
    - nucleardog 6y ago
      No reason the server can’t provide a nonce for the login to salt the hash.
      - withinboredom 6y ago
        And how would the server know the desalted hash?
      - Sir_Substance 6y ago
        Now the server has to store the password in plain text so it can rehash with the new nonce every time.
MiroF 6y ago
> Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. Sure, if you're foolish enough to not hash on the server side then you're setting yourself up for failure. But I fail to see what the problem with hashing on the client side is?
- fhars 6y ago
  It doesn’t hurt much, but it doesn’t help much either, especially for web applications. If the user cannot trust that the server doesn’t do bad things with the password, they also cannot trust the javascript hash function sent from the same server, so it does not protect against the scenario discussed here. And it is no substitute for an encrypted connection.
  - arghwhat 6y ago
    No, it does hurt. It also means that you're making up crypto protocols, which is not something you do for fun. Use SRP or similar if you need private password transfers (which again is still pointless if the client isn't trusted).
derangedHorse 6y ago
Exactly. Using a password manager is probably the most secure thing that can be done these days given your password for the password manager is secure (which it most likely will be due to the stringent complexity requirements for some of these services)

jialutu 6y ago

Thanks, corrected :)

gpm 6y ago

> Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. I've yet to see someone give a good reason to not hash on the client and the server... I would be curious to hear if you have any. It's definitely non-standard though.

Zimahl 6y ago
Isn't the main security feature of hashing that you hash against a salt and that no one but the server knows the salt? Once you send the salt to the client (and anything on the client should be considered insecure) you give the ability to generate lookup tables for common passwords. Without the salt it's much harder to brute-force the password.
- fhars 6y ago
  No, the salt can be public (it was on Unix machines before the invention of /etc/shadow). The important thing is that it is unique per password, so that Hash(Salt#Password) is unique even if two passwords happen to be the same.
- nikisweeting 6y ago
  Just use a different salt on the client and server. (and potentially even a different salt for each client)
- UncleMeat 6y ago
  No. Salts are not intended to be secrets. The expectation is that in the case of a breach that salts are also exposed. What they do is prevent precomputation of lookup tables, granting the developer a bit of time after a breach before all bets are off.
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 ago
  I 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.
  - ht85 6y ago
    > server's 2-way Are thinking of encoding / decoding? If so it isn't used for passwords.
    - devado 6y ago
      indeed, scratch that. i rewrote that comment a couple of times, and that 2-way part is of course not correct. this would defeat the point of hashing passwords if they were reversible
- 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.
mneubrand 6y ago
You can't enforce complexity rules or check against known leaked passwords or that they don't reuse username as password or anything like that if you hash on the client too
- ALittleLight 6y ago
  You can check complexity or username reuse client side. You could even block the n most common passwords clientside if you wanted to.
  - phab 6y ago
    But I could just ignore/comprimise/modify your client and submit whatever I liked to the server.
    - smolder 6y ago
      What's the motivation of someone able to do that and interested in doing it?
      - SiNiquity 6y ago
        Primarily to get around arbitrary password rules that do not enhance the security of the password but serve to weaken it, e.g. only use special characters from this list: !@#, or sorry your password is TOO LONG (?!)
    - labawi 6y ago
      That's true, but only to a point. You can actually server-side check username/password equality, and a not overly long list of other unwanted passwords. You just have to check each one.
progre 6y ago
Wouldn't hashing on the client side possibly introduce a reduction in complexity of the password? The hashed password on the client side could be used in place of the plaintext password if the channel is insecure. Lets say the password length limit is 256 ascii chars this is 8*256 bits (ok a little less since not all ascii chars are printable), but if hashed on the client (lets be generous and hash to 1024 bits) it's still half the complexity of the plaintext.
- ALittleLight 6y ago
  I'm not understanding this. Couldn't you choose an arbitrary amount of bits to hash to on the client side?
- smolder 6y ago
  It's less about bits and more about entropy. Passwords tend to be low on entropy because of words and patterns present in the sequence. Its almost always going to be harder to break passwords by trying every possible hash than doing dictionary attacks against plaintext passwords. 256 bits is around 37 characters of base64 text. Compare that to most passwords and it's safe to say they aren't losing entropy when hashed.
- johannes1234321 6y ago
  If you are not including humans your maths might be right. With humans not all 8 bits of extended ASCII are realistically used in passwords. And rarely you get passwords longer than 10 characters. And then: By the password not leaving the system you avoid another issue with humans: If the hash is lost (accidental logging and locks leaking and such things happen) this won't allow to sign in to other accounts, where the lazy human used the same password. For machine-to-machine communication tokens with higher entropy can and should be used.
- gpm 6y ago
  A 128 bit random plaintext is more than secure enough... If you're trying to argue that the user puts in, say, 60 bits of entropy, and that the hashing algorithm is going to accidentally throw out 10 of those to result in 50 bits of entropy, I believe that any hashing algorithm that did that in a way that anyone can exploit with realistic computing power (a computer smaller than the size of the solar system) would be considered irredeemably broken.
arghwhat 6y ago
1. If the client is written by the same people as the server, then it provides no improvement in password confidentiality. 2. It provides no additional security in the authentication process. 3. It provides no additional security-at-rest for post-breach protection. Doing something like that ends up in the dangerous bucket of duct-tape crypto. I don't mind people playing with crypto, but things are not as simple as they seem, and "more" is not necessarily better.
- SiNiquity 6y ago
  The client in this case should be the web-browser; it shouldn't be custom Javascript. There should be an attribute on the password field that says if the password should be hashed before sent to the server. It could also be salted by the browser to reduce reuse across sites similar to any password manager today.
smolder 6y ago
Hashing twice, on the client as well as on the server, won't introduce any security issues if the choice of algorithm is good, and it does further protect the users password from being harvested from passive MITM'd SSL like it is on some corporate networks. (Yes I know MITM means they could rewrite the client to steal passwords, but that's work) If I was designing a password auth scheme that highly prioritized user security, I would hash both client and server side.
- Sir_Substance 6y ago
  >and it does further protect the users password from being harvested from passive MITM'd SSL like it is on some corporate networks. It might protect the password if the user is reusing it elsewhere, but it doesn't protect the account the password is securing during the intercepted transmission. The MITM attacker can just replay the hash.
  - nucleardog 6y ago
    No reason the server can’t provide a nonce for the login to salt the hash.
    - withinboredom 6y ago
      And how would the server know the desalted hash?
    - Sir_Substance 6y ago
      Now the server has to store the password in plain text so it can rehash with the new nonce every time.

MiroF 6y ago

> Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. Sure, if you're foolish enough to not hash on the server side then you're setting yourself up for failure. But I fail to see what the problem with hashing on the client side is?

fhars 6y ago
It doesn’t hurt much, but it doesn’t help much either, especially for web applications. If the user cannot trust that the server doesn’t do bad things with the password, they also cannot trust the javascript hash function sent from the same server, so it does not protect against the scenario discussed here. And it is no substitute for an encrypted connection.
- arghwhat 6y ago
  No, it does hurt. It also means that you're making up crypto protocols, which is not something you do for fun. Use SRP or similar if you need private password transfers (which again is still pointless if the client isn't trusted).

derangedHorse 6y ago

Exactly. Using a password manager is probably the most secure thing that can be done these days given your password for the password manager is secure (which it most likely will be due to the stringent complexity requirements for some of these services)