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)

> 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

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).

better to put the pw in a physical token than have some short guessable pw

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

Typically compatibility with legacy systems

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.

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.

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.

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