Django Security Release - 1.5.4 | Hacker News Reader

Django Security Release - 1.5.4

djangoproject.com

125 pointsgandalfar24 comments

Sometimes we do releases that fix things that are kinda hard to exploit, or mostly are just hardening existing stuff to make it even better.

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.

FYI,

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

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

Why should an end-user need to comprehend a limit in bytes at all? Good points though!

Specifically with UTF-8 it depends on the content how many characters fit in these 4096 bytes.

From the patch, it doesn't look like it's bytes, but characters.

Where do you see this? In https://github.com/django/django/commit/aae5a96d5754ad34e48b... they specifically mention bytes.

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.

"characters" is an unfortunately common shortcut for "code points" as that's what unicode-based "char" types tend to mean.

And my comment was an explanation of an other user's, nothing more.

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

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

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.

4096 is a convenient power of 2, and is the same as the default limit enforced by passlib (a popular password-hashing tool in Python).

Just for kicks, I timed how long it took to hash a 1Mb password on an EC2 small instance:

>>> timeit.timeit('make_password(a, "asdfasdfasd")', setup="a = 'a' * 1024 * 1024; from django.contrib.auth.hashers import make_password;", number=1) 206.77019500732422

What I believe to be the relevant post that prompted these releases: http://www.mail-archive.com/django-developers@googlegroups.c...

Yep, I was the doofus that posted to django-developers, rather than security@. Sorry if I complicated anyone's weekend.

Well, thank you for noticing and bringing it to the attention of the development team even through it was through the wrong channel. :-)

Reply on news.ycombinator.com