> 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
