3 ms·

There's also the "exactly 8" limit increased to "8 to 18". Why even have those limits? If you're hashing it there's no reason to have a limit at all.

kngspook 12y ago
I've always wondered this... So many organizations do this.
- eli 12y ago
  Typically compatibility with legacy systems
  - nemanja 12y ago
    That shouldn't be a factor if passwords are hashed, right? In other words, you don't have plain-text to pass on to the legacy system.
    - akjsdfh 12y ago
      I was once told it was to prevent DoS-ing the back end of the system by submitting gigabytes to hash... the check was an HTML input limit and there was no backend limit... I was sad.
    - eli 12y ago
      Maybe the interface expects an 8 character password even if it's hashed on the backend. Maybe it's hashed by something that expects a certain length because it's using a silly algorithm. Maybe not all systems use hashed passwords. Hard to say from the outside, but in my experience it's usually not because the developers were stupid or ignorant.
- deleted 12y ago
  [deleted]
nemanja 12y ago
I always thought that the max is there to discourage users from setting passwords so long they can't remember them (and instead write them down on a post-it that's right on the monitor).
- gohrt 12y ago
  better to put the pw in a physical token than have some short guessable pw
serioussecurity 12y ago
I believe old versions of mailman fall on their face when using pw more than 8 chars.
mappu 12y ago
In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation, where arbitrary-length passwords could DoS the server. An upper bound is probably a safe thing to have (but 18 is too low)
- masklinn 12y ago
  > In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation CVE-2013-5750 is a Symfony vulnerability, the Django one is CVE-2013-1443. And of course it was fixed by limiting passwords to 4096 bytes, not 18. An easy alternative (which has to be applied if you're using bcrypt since it's limited ~50 bytes of input) is applying length reduction through a regular cryptographic hash before applying the KDF[0]. Of course the cryptographic hash might still be DOS'd, but they tend to have a throughput of 100~300MB/s on commodity hardware so that's less likely. [0] HMAC actually does that internally: if the key (password) is bigger than BLOCKSIZE — 64B for hmac-md5 and hmac-sha1, it will pass it through the hash function once then pad it to BLOCKSIZE before doing its thing. The pkbdf2 DOS is because PBKDF2-HMAC calls HMAC once per round, so (on passwords longer than BLOCKSIZE) it performs length reduction once per round, and the total input data for length reduction alone is thus rounds * pw_length. Given pbkdf2 tends to have round counts in the tens of thousands or hundreds of thousands these days, the amount of data going through the hash function literally increases by several orders of magnitude… and for nothing since it's the exact same operation each round. Thus running e.g. SHA-384 on a password before handing it off to a KDF is probably a good idea in any case

kngspook 12y ago

I've always wondered this... So many organizations do this.

eli 12y ago
Typically compatibility with legacy systems
- nemanja 12y ago
  That shouldn't be a factor if passwords are hashed, right? In other words, you don't have plain-text to pass on to the legacy system.
  - akjsdfh 12y ago
    I was once told it was to prevent DoS-ing the back end of the system by submitting gigabytes to hash... the check was an HTML input limit and there was no backend limit... I was sad.
  - eli 12y ago
    Maybe the interface expects an 8 character password even if it's hashed on the backend. Maybe it's hashed by something that expects a certain length because it's using a silly algorithm. Maybe not all systems use hashed passwords. Hard to say from the outside, but in my experience it's usually not because the developers were stupid or ignorant.
deleted 12y ago
[deleted]

nemanja 12y ago

I always thought that the max is there to discourage users from setting passwords so long they can't remember them (and instead write them down on a post-it that's right on the monitor).

gohrt 12y ago
better to put the pw in a physical token than have some short guessable pw

serioussecurity 12y ago

I believe old versions of mailman fall on their face when using pw more than 8 chars.

mappu 12y ago

In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation, where arbitrary-length passwords could DoS the server. An upper bound is probably a safe thing to have (but 18 is too low)

masklinn 12y ago
> In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation CVE-2013-5750 is a Symfony vulnerability, the Django one is CVE-2013-1443. And of course it was fixed by limiting passwords to 4096 bytes, not 18. An easy alternative (which has to be applied if you're using bcrypt since it's limited ~50 bytes of input) is applying length reduction through a regular cryptographic hash before applying the KDF[0]. Of course the cryptographic hash might still be DOS'd, but they tend to have a throughput of 100~300MB/s on commodity hardware so that's less likely. [0] HMAC actually does that internally: if the key (password) is bigger than BLOCKSIZE — 64B for hmac-md5 and hmac-sha1, it will pass it through the hash function once then pad it to BLOCKSIZE before doing its thing. The pkbdf2 DOS is because PBKDF2-HMAC calls HMAC once per round, so (on passwords longer than BLOCKSIZE) it performs length reduction once per round, and the total input data for length reduction alone is thus rounds * pw_length. Given pbkdf2 tends to have round counts in the tens of thousands or hundreds of thousands these days, the amount of data going through the hash function literally increases by several orders of magnitude… and for nothing since it's the exact same operation each round. Thus running e.g. SHA-384 on a password before handing it off to a KDF is probably a good idea in any case