

Django Security Release - 1.5.4 - gandalfar
https://www.djangoproject.com/weblog/2013/sep/15/security/

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

------
dchest
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...](https://en.wikipedia.org/wiki/Blowfish_\(cipher\)#The_algorithm))

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

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

~~~
andyroid
"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!

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

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

~~~
Perseids
Where do you see this? In
[https://github.com/django/django/commit/aae5a96d5754ad34e48b...](https://github.com/django/django/commit/aae5a96d5754ad34e48b7f673ef2411a3bbc1015#L3R405)
they specifically mention bytes.

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

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

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

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

------
djthrowaway86
What I believe to be the relevant post that prompted these releases:
[http://www.mail-archive.com/django-
developers@googlegroups.c...](http://www.mail-archive.com/django-
developers@googlegroups.com/msg38236.html)

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

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

