form validation in contrib.auth

[Jens Diemer]

The default auth.form.AuthenticationForm() did not set a max_length for the
password field:

https://github.com/django/django/blob/72f6513ebaa7a3fd43c26300e9a8c430dc07cdb5/django/contrib/auth/forms.py#L120-L126

Ok there is not really a max_length constraint. Because in the end the
auth.models.User must only store the hash value.

The available hashers will consume more RAM if the password is very long. (The
CPU usage is very similar to a short password)
Only if the server has a POST data limit, the password size is limited. But it
seems that POST limits are not set or very large on default installations...


On the other side: I didn't see any side effects with a limitation e.g.:
max_length=1024




Another thing: The auth.models.AbstractUser has the 'username' field with
max_length=30 and validators.RegexValidator(r'^[\w.@+-]+$',...)

The AuthenticationForm has max_length=254 and no validator...



IMHO one principle is: Validate incoming data as soon as possible, isn't it?



Next thing is "auth.signals.user_login_failed"

This signal will only fired if the auth backends was called.
IMHO it should be called on every failed login. Also if the form is not valid.






--


Mfg.

Jens Diemer


----
http://www.jensdiemer.de

[Tim Graham]

1. I don't see much benefit to adding a max length for one form (AuthenticationForm) to give some sense of security as opposed to properly addressing the issue at the webserver level. As Paul said, "As documented in the deployment docs, it is your responsibility as the deployer to limit post bodies to a size which is reasonable for your server. Otherwise, a user can make very large post requests to any view at all, which may overwhelm other parts of your web stack as well. 4k is a commonly accepted good starting point for forms which do not expect file upload; you will have to tune file upload forms to match your needs depending on how they're processed."

2. AuthenticationForm is intentionally generic to allow it to be used with custom user models which may have different restrictions on the user name.

3. What's the use case? I'm not sure the signal without any credentials would be of much value. Anyway, it shouldn't be difficult to write your own login() view with the behavior you desire if we don't make a change in Django.