5 ms·

This is what happens when compliance rules force sites to have specific policies. Especially when you have more than one set of rule combined. With that said,

by throwaway2016a 4y ago

This is what happens when compliance rules force sites to have specific policies. Especially when you have more than one set of rule combined. With that said, a lot of these seem pretty reasonable. The one that I really don't get that keeps appearing is max length though. I get that they may not want to allow you to have a 10MB password but I think a reasonable max like 500 characters would be better. A max length of 8 makes me think they are storing the unhashed password in a VARCHAR. Also, from a UX perspective some of these rules may be best to only tell the user about if they actually trigger it. Like "most not contain username" is uncommon enough they can probably only show it if it actually happens. Same with "cannot reuse last 4"

diarrhea 4y ago
Cryptographic password hashing functions such as bcrypt have relatively low maximums. Bcrypt sits at 72 characters, which if you used 4-byte UTF-8 is pretty short, for example. Bcrypt is outdated but still widely used, I reckon.
- throwaway2016a 4y ago
  I actually didn't know that about Bcrypt. Good to know! Thank you. Though, 72 (18 if using 4 byte) would still be better than 10. Edit: Also as OWASP suggestions (I thought of it but wanted to verify if it was OK before I posted)... if you're using Bcrypt you could hash it with something like sha256 before running it through Bcrypt to get around the length limit. Edit: mistyped "bit" instead of "byte" :(
- wongarsu 4y ago
  Wouldn't this be easily solved by giving bcrypt the sha512 of the password? Though 72 or 36 characters max really isn't so bad.
  - throwaway2016a 4y ago
    If you check out the Bcrypt section of OWASP[1] this is exactly what they suggest. [1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#:~:text=bcrypt%20has%20a%20maximum%20length,be%20enforced%20when%20using%20bcrypt https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor....
    - wongarsu 4y ago
      Interesting, that page links to two problems that can appear: - bcrypt implementations that assume zero-terminated strings, which leads to easy attacks if you feed them raw hashes (1/256 chance that the first byte is 0, so on average every 256th user has a password that has a hash collision with with one in every 256 passwords) - password shucking, which is where the attacker has hash(password) from other breaches (where hash is sha256 or similar), and you use bcrypt(hash(password)) (with the same hash function), which allows the attacker to bcrypt the hashes he has, compare them, and if any match can attack the much weaker hash(password). Which is probably why their version uses `bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)`. That seems complicated, bu the base64 encoding avoids the first issue, and the pepper the second. I guess that shows how easy it is to get these things wrong, even if it seems trivial.
thesuitonym 4y ago
>from a UX perspective some of these rules may be best to only tell the user about if they actually trigger it. This is fine if you have reasonable password policies, but I've run up against incredibly frustrating password requirements that were hidden until I triggered them. The workflow went like this: Password manager generates a password, attempt to submit. "Password must be less than 20 characters" OK, regenerate a new password at 19 characters. "Password must include at least one special character." ...OK, add special characters in the list. "Password cannot contain %." If they just told me all of the rules at the beginning, I could have made sure my password worked the first time.
- throwaway2016a 4y ago
  Yeah, kind of a lesser of two evils sort of thing. Though immediate validation client-size would help. The best UX would be to just not have ridiculous rules like "cannot contain %" I was referring more to the "cannot be the same as last 4" policy and things like really long password lengths (too long to expect a reasonable person to type in). If your max length is, say 500, you probably don't need to include it in a long list because a reasonable person would never hit 500.

diarrhea 4y ago

Cryptographic password hashing functions such as bcrypt have relatively low maximums. Bcrypt sits at 72 characters, which if you used 4-byte UTF-8 is pretty short, for example. Bcrypt is outdated but still widely used, I reckon.

throwaway2016a 4y ago
I actually didn't know that about Bcrypt. Good to know! Thank you. Though, 72 (18 if using 4 byte) would still be better than 10. Edit: Also as OWASP suggestions (I thought of it but wanted to verify if it was OK before I posted)... if you're using Bcrypt you could hash it with something like sha256 before running it through Bcrypt to get around the length limit. Edit: mistyped "bit" instead of "byte" :(
wongarsu 4y ago
Wouldn't this be easily solved by giving bcrypt the sha512 of the password? Though 72 or 36 characters max really isn't so bad.
- throwaway2016a 4y ago
  If you check out the Bcrypt section of OWASP[1] this is exactly what they suggest. [1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#:~:text=bcrypt%20has%20a%20maximum%20length,be%20enforced%20when%20using%20bcrypt https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor....
  - wongarsu 4y ago
    Interesting, that page links to two problems that can appear: - bcrypt implementations that assume zero-terminated strings, which leads to easy attacks if you feed them raw hashes (1/256 chance that the first byte is 0, so on average every 256th user has a password that has a hash collision with with one in every 256 passwords) - password shucking, which is where the attacker has hash(password) from other breaches (where hash is sha256 or similar), and you use bcrypt(hash(password)) (with the same hash function), which allows the attacker to bcrypt the hashes he has, compare them, and if any match can attack the much weaker hash(password). Which is probably why their version uses `bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)`. That seems complicated, bu the base64 encoding avoids the first issue, and the pepper the second. I guess that shows how easy it is to get these things wrong, even if it seems trivial.

thesuitonym 4y ago

>from a UX perspective some of these rules may be best to only tell the user about if they actually trigger it. This is fine if you have reasonable password policies, but I've run up against incredibly frustrating password requirements that were hidden until I triggered them. The workflow went like this: Password manager generates a password, attempt to submit. "Password must be less than 20 characters" OK, regenerate a new password at 19 characters. "Password must include at least one special character." ...OK, add special characters in the list. "Password cannot contain %." If they just told me all of the rules at the beginning, I could have made sure my password worked the first time.

throwaway2016a 4y ago
Yeah, kind of a lesser of two evils sort of thing. Though immediate validation client-size would help. The best UX would be to just not have ridiculous rules like "cannot contain %" I was referring more to the "cannot be the same as last 4" policy and things like really long password lengths (too long to expect a reasonable person to type in). If your max length is, say 500, you probably don't need to include it in a long list because a reasonable person would never hit 500.