5 ms·

Reasonable upper limits don't bother me all that much. If you're going to store a hashed password, you want to choose an expensive hash algorithm (It's been a w

Reasonable upper limits don't bother me all that much. If you're going to store a hashed password, you want to choose an expensive hash algorithm (It's been a while since I looked at this, but I don't think bcrypt is standard anymore?) and that complexity is meant to be computationally ridiculous, and probably scales with length. Good security dictates a minimum length, and practical avoidance of your login form being a denial of service... well, that dictates a maximum length too. It can be quite long, but you generally should not allow bot makers to instruct your login handler to actually hash the entire declaration of independence, repeatedly. (Edit: I should clarify, by "reasonable" I'm talking like, 200 character or more reasonable. These sites with 20 character maximums make me cringe. Also the computational complexity can be mitigated in other ways, like sensible rate limiting.)

skunkworker 7y ago
Bcrypt is still widely used. It’s just advised to increase your work factor to something at least 12 if not 14+. And every year or two bump it up another level.
- nobleach 7y ago
  So: `val factor = currentYear - YEAR_APP_WRITTEN + 14`?
FabHK 7y ago
> that complexity is meant to be computationally ridiculous, and probably scales with length. I'd think that there is an initial hashing (which is quite fast), and then iterated computations on that fixed length, with a more or less predictable (and high) CPU and memory intensity - in other words, not (significantly) scaling with length.
ChrisSD 7y ago
bycrypt has a limit of 72 bytes (not characters) and possibly less depending on the specific implementation. Theoretically this could limit you to only 18 characters if your password is utf-8 encoded emoji (4 bytes per character). This can be worked around by the server hashing the password using a fast hash before passing it to bcrypt but this risks reducing the security of the password.
- eru 7y ago
  No, this doesn't reduce the security of the password at all, if your first fast hash is well distributed. Eg use the first 72 bytes of SHA256, if you like overkill.
hannasanarion 7y ago
Why not have one round of hashing in the browser? That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.
- zeta0134 7y ago
  Wouldn't that just turn the attacker's problem into brute forcing the client-side hash? Might be a problem if the client-side hash has a lower total complexity than the longer original password. I dunno though; just pondering out loud, I'm by no means an expert on this stuff.
  - eru 7y ago
    Yes, obviously. So you choose something like 1024 bits as the length of the client hash. The client hash doesn't even need to be any good, even xor-ing blocks might work. It just needs to preserve a lot of entropy.
  - hannasanarion 7y ago
    But the hash would necessarily preserve the entropy of the password. A 256 bit hash is about as strong as a 32 character random password. According to the password haystack, that would take "6.22 hundred trillion trillion trillion trillion centuries" to crack in an online attack. If you choose to attack such a scheme by guessing the hash, then all passwords have that same level of entropy, even if the password that generated the hash is only 8 characters.

skunkworker 7y ago

Bcrypt is still widely used. It’s just advised to increase your work factor to something at least 12 if not 14+. And every year or two bump it up another level.

nobleach 7y ago
So: `val factor = currentYear - YEAR_APP_WRITTEN + 14`?

FabHK 7y ago

> that complexity is meant to be computationally ridiculous, and probably scales with length. I'd think that there is an initial hashing (which is quite fast), and then iterated computations on that fixed length, with a more or less predictable (and high) CPU and memory intensity - in other words, not (significantly) scaling with length.

ChrisSD 7y ago

bycrypt has a limit of 72 bytes (not characters) and possibly less depending on the specific implementation. Theoretically this could limit you to only 18 characters if your password is utf-8 encoded emoji (4 bytes per character). This can be worked around by the server hashing the password using a fast hash before passing it to bcrypt but this risks reducing the security of the password.

eru 7y ago
No, this doesn't reduce the security of the password at all, if your first fast hash is well distributed. Eg use the first 72 bytes of SHA256, if you like overkill.

hannasanarion 7y ago

Why not have one round of hashing in the browser? That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.

zeta0134 7y ago
Wouldn't that just turn the attacker's problem into brute forcing the client-side hash? Might be a problem if the client-side hash has a lower total complexity than the longer original password. I dunno though; just pondering out loud, I'm by no means an expert on this stuff.
- eru 7y ago
  Yes, obviously. So you choose something like 1024 bits as the length of the client hash. The client hash doesn't even need to be any good, even xor-ing blocks might work. It just needs to preserve a lot of entropy.
- hannasanarion 7y ago
  But the hash would necessarily preserve the entropy of the password. A 256 bit hash is about as strong as a 32 character random password. According to the password haystack, that would take "6.22 hundred trillion trillion trillion trillion centuries" to crack in an online attack. If you choose to attack such a scheme by guessing the hash, then all passwords have that same level of entropy, even if the password that generated the hash is only 8 characters.