- bcrypt can have passwords up to 72 bytes (depending on implementation) due to its nature of feeding password into a block cipher, and Blowfish having max 448 bit keys but some implementations allowing 576 bits (see https://en.wikipedia.org/wiki/Blowfish_(cipher)#The_algorith...)
- scrypt accepts passwords of unlimited length, however the computational/memory cost doesn't depend on password length, as the first step in scrypt is expanding (or compressing) password and salt with 1-round PBKDF2, which is basically HMAC in counter mode.
Some people deride it as "C programmer mentality" when fields have a fixed maximum size. I too used to think having no limits at all was the best approach in most scenarios. But for many user input data, there is a point at which a longer value is complete nonsense. The 4096-character password length limit Django will now employ seems quite a bit longer than absolutely necessary; hopefully it sufficiently addresses the bug. As for the choice of 4096, well, I would have chosen 4000 (or 1000) simply because it's more comprehensible from an end-user perspective.
When designing such systems, also consider that users sometimes accidentally copy-paste entire documents into text fields--given the number of users Django has, if a site has no input-field length limit, it's downright likely that someone will eventually paste a megabyte "password" in there with no ill intention.
> But for many user input data, there is a point at which a longer value is complete nonsense.
The reason I still prefer arbitrary length fields is that I otherwise have to determine the limit myself. And finding reasonable limits isn't always that easy. For example, quite a few sites have about 20 chars as maximum password lengths. Using xkcd's correct-battery-horse-staple method (or formerly most commonly known as diceware) this assumption already fails. Also, what is the correct maximum length for a surname? (See Janice Keihanaikukauakahihuliheekahaunaele.) And then there are these ridiculously short text fields for complaints or questions on sites like UPS that only allow like 400 characters (how these are encoded into bytes raises other questions about how reasonable that limit is). I'd argue it's more work to find out the right limits than to implement arbitrary length fields.
In the case of PBKDF2 I would say it's the primitive's (PBKDF2's) fault for allowing a DOS on long passwords. I do not blame the designers though. I have read its definition several times and have never though about DOS attacks, too. Like with padding oracle or length extension attacks this should go on the check list for future designs and PBKDF2 should be phased out.
Mostly they shouldn't need to, but on the off chance it is documented somewhere, it may as well be a "big round number" in human terms rather than computer ones. I often wonder why programmers gravitate powers of two even in places where it doesn't matter (as opposed to say small datatype sizes, where powers of two are useful).
MAXIMUM_PASSWORD_LENGTH is used as the max_length of CharField. CharField are unicode, and thus if one reads no further than django/contrib/auth/forms.py and doesn't see MAXIMUM_PASSWORD_LENGTH is also used on KDFs input (which work on bytes) one may get the impression that it's a limit on code units.
Then it's Unicode code points, which are still am abstract concept to users. The only thing that's meaningful to users is graphemes — and with Unicode one grapheme can be formed of a potentially infinite number of code points (continuation characters stack, and can be repeated indefinitely), so you cannot practically use that for any limit.
Yeah, that is what I am saying. They keep saying that they limited the length of passwords to 4096 bytes, but they actually limited them to 4096 characters.
Nope. MAXIMUM_PASSWORD_LENGTH is used both as the limit of CharField and as the limit of KDFs. CharField is unicode[0] and thus work on code units (codepoints in Python 3.3, depends whether the build is narrow or wide in previous versions) but KDFs work on bytes.
You can see that clearly in the test suite, where the input of KDFs are byte objects:
because the number of code units is at most the number of input bytes (with fixed-width 8-bit encodings), KDFs will be the limiting factor and the limit is thus 4096 bytes.
Sometimes we do releases because there's a serious exploitable thing in the wild.
This is the latter: it's a DoS vector, and it got out via a posting to a public mailing list. Please do not hold off on upgrading.