Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed #16860 -- Added password validation to django.contrib.auth #4276

Closed
wants to merge 1 commit into from
Closed

Fixed #16860 -- Added password validation to django.contrib.auth #4276

wants to merge 1 commit into from

Conversation

mxsasha
Copy link
Member

@mxsasha mxsasha commented Mar 8, 2015

  • Aggregate all validation errors.
  • Aggregate all requirements with HTML lists.
  • Call a method on each validator after a successful change.
  • Validator for most common passwords.
  • See whether similarity errors can be made more specific.
  • Look into performance impact of current similarity validator.
  • Tests
  • Docs
  • Look into alternative way for validators to return their failures per Aymeric's suggestion.
  • Look into alternative design which does not require a global setting.
  • Ensure the common password list is cached.
  • Add validator to check for fully numerical passwords.
  • Release notes

https://code.djangoproject.com/ticket/16860
Mailing list discussion on: https://groups.google.com/forum/#!topic/django-developers/9GBhgGXmEKs

@@ -534,6 +534,8 @@
'django.contrib.auth.hashers.CryptPasswordHasher',
]

PASSWORD_VALIDATORS = []
Copy link
Member

@charettes charettes Mar 8, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is part of a contrib application I think this should be named AUTH_PASSWORD_VALIDATORS.

@mxsasha mxsasha assigned kmtracey and unassigned kmtracey Mar 14, 2015
@mxsasha
Copy link
Member Author

mxsasha commented Mar 14, 2015

Didn't actually mean to assign this to Karen, must have misclicked somewhere :)

@mxsasha
Copy link
Member Author

mxsasha commented Apr 11, 2015

I don't know entirely what's going on, but those build failures do not appear to be related to the patch:

 > git checkout -f fe70cd410fbc419a4881099ab3034d0f72d629ed
FATAL: Could not checkout null with start point fe70cd410fbc419a4881099ab3034d0f72d629ed
hudson.plugins.git.GitException: Could not checkout null with start point fe70cd410fbc419a4881099ab3034d0f72d629ed

Most platforms do seem to succeed.

@MarkusH
Copy link
Member

MarkusH commented Apr 11, 2015

That's one of Jenkins occasional hiccups. No need to worry.

from django.utils.translation import ugettext as _


def get_password_validators():
Copy link
Member

@jarshwah jarshwah Apr 11, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be cached? The number of times validators are instantiated, and the associated cost with loading in the 1000 most common passwords each time strongly suggests that it should be.

Copy link
Member Author

@mxsasha mxsasha Apr 11, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, actually, definitely.

Copy link
Member

@aaugustin aaugustin Apr 11, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm theoretically reluctant to this being a global module rather than something tied to the User model.

In practice AUTH_USER_MODEL is already a global singleton so this doesn't change the picture.

(Sorry if I brought this up before.)

Copy link
Member

@aaugustin aaugustin Apr 11, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jarshwah Agreed. The cache must be cleared by a setting_changed receiver.

Copy link
Contributor

@jezdez jezdez Apr 12, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to second @aaugustin's point about this conceptually fitting very well into the custom user models. This does not require yet another setting, so let's not.

On the bigger picture I really would like to prevent settings.py to continue to turn into a file full of dictionaries with dotted Python paths and initialization parameters. Let's use the extension API we've built into the auth app for such a case.

Copy link
Member Author

@mxsasha mxsasha Apr 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get your point, but I'm not entirely seeing what you are proposing. Could you make a short example? As this is a more fundamental design discussion, perhaps this would fit best on the django-developers list.

(I'll defer working/responding on other comments until we've settled this issue, as we need to get this right to have a mergeable patch.)


Included validators
-------------------
Django includes three validators:
Copy link
Member

@timgraham timgraham Apr 11, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need a .. module:: directive hear, otherwise you inherit the last one which is django.contrib.auth.hashers.

@MarkusH
Copy link
Member

MarkusH commented Apr 11, 2015

As @aaugustin mentioned elsewhere, compression the common passwords list sounds like a good idea in combination with customizing its location.

How hard would it be to add some autodetection if the file needs to be unzipped or is already a plain-text file? Plain text files are easier to maintain for project specific lists, I think.

'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
Copy link
Contributor

@wimfeijen wimfeijen Apr 12, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is NAME in capitals?

For comparison, DATABASES and CACHES use lower-case 'default' and then capitals, LOGGING uses lower-case only.

Copy link
Member

@MarkusH MarkusH Apr 12, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it's a predefined identifier, similar to ENGINE and NAME in the DATABASES setting and BACKEND and DIRS in TEMPLATES.

@jezdez
Copy link
Contributor

jezdez commented Apr 12, 2015

Ough, is a new setting really required for this?

@timgraham timgraham changed the title WIP - Added password validation to django.contrib.auth [WIP] Fixed #16860 -- Added password validation to django.contrib.auth Apr 16, 2015
@mxsasha
Copy link
Member Author

mxsasha commented Apr 26, 2015

@jezdez, @aaugustin: as both of you have proposed to tie this to the User model, could you write up a short example? I may have some concerns about that design, but I'd rather form an opinion on an example rather than my imagination of what I think your idea might be. Perhaps I'm entirely mistaken.

As this is a more fundamental design discussion, perhaps this would fit best on the django-developers list rather than this PR.

@mxsasha mxsasha changed the title [WIP] Fixed #16860 -- Added password validation to django.contrib.auth Fixed #16860 -- Added password validation to django.contrib.auth Jun 5, 2015

def get_password_validators(validator_config=None):
validators = []
if validator_config is None:
Copy link
Member

@carljm carljm Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're going to provide get_default_password_validators, why not move this into that function and make get_password_validators entirely settings-independent, with the config arg required?

@carljm
Copy link
Member

carljm commented Jun 5, 2015

This is great! Very excited to have this in Django 1.9; I think I'm about to backport it into a 1.8 project I'm working on currently :-) Thanks for working on it!

@carljm
Copy link
Member

carljm commented Jun 5, 2015

Of the comments I just left, the only one I would consider a merge blocker is the vague error message issue.

@alexbecker
Copy link
Contributor

alexbecker commented Jun 21, 2015

Is there a reason why password validation is not performed on UserCreationForm?

@timgraham
Copy link
Member

timgraham commented Jun 22, 2015

This was merged in 1daae25.

@timgraham timgraham closed this Jun 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet