Hi Erik, This nice, though I'd like it even more if it didn't introduce another setting. :) Having it on the backend would solve that problem for me I think.
Also, this may be obvious, but more specific error messages would be nice, like "password is too simliar to username". Collin On Monday, March 9, 2015 at 5:43:36 PM UTC-4, Aymeric Augustin wrote: > > Hi Erik, > > Great work! > > Did you consider tying validators to authentication backends? I admit it > sounds like a bad idea and most likely it is, but since different backends > may have different security requirements, I'd like to make sure we aren't > missing something. > > Assuming help_text is HTML, you may improve it by building it as follows: > > <p>Your password must match the following requirements:</p> > <ul> > <li>validator 1's requirements</li> > ... > </ul> > > This version looks slightly worse when there's only one validator. However > I expect most sites will use at least two or three validators: minimum > length, character classes (lower/upper/figures), not a common password (we > should ship a static blacklist of the top 100 most common passwords, > there's tons of research on this). > > In order to prevent reuse of old passwords, you need to add another method > to the validator class that is called after the password is successfully > changed. Otherwise, if the user submits a password change form and the new > password goes through the validators successfully but the submission fails > for some other reason (e.g. the current password is wrong), then the user > can't re-submit the same new password, even though they never used it. > > -- > Aymeric. > > > Le 8 mars 2015 à 15:47, Erik Romijn <ero...@solidlinks.nl <javascript:>> > a écrit : > > > > Hello all, > > > > I've taken another stab at 16860[1]: having a password validation/policy > in Django. I've made an initial simple PR[2] to show the approach I'd like > to use - no tests or documentation yet, the example validators are not very > nice, possibly bad naming, etc. But this should be sufficient to show how I > would like to tackle this. There's quite a few decisions to take, > influencing the later possibilities, which I'll try to outline below. > > > > Users choosing awful passwords is a serious security issue. Although > password validation can only go so far - especially to the extent that we > can implement in Django itself - to me it seems part of our responsibility > in helping Django developers to build safer websites. > > > > First, let me briefly describe my approach: we add a new setting to > define zero or more password validator classes. Optionally, a class can be > provided with custom arguments to it's constructor. Each validator class > has a help_text() method and a validate(password, user) method. The former > produces a translatable sentence to be included in the form field's help > text. The validate method validates a certain password, optionally taking > the context of a user into account and passes its judgement on the > password. If a validator considers a password insufficient, it raises a > ValidationError. > > > > This is tied to the validation and form field setup in SetPasswordForm > and AdminPasswordChangeForm. An obvious choice seems to be to tie this to > User.set_password(). However, I intentionally did not include that step, as > I feel this validation should primarily take place on the user frontend > site with forms. This mirrors the way we typically handle this in Django. > Should someone feel different, and want to tie this to set_password() as > well, this is possible with a custom user object. Tying this validation > into any other place is also trivial: just adding a single line. > > > > I decided not to go for standard Django validators, as I felt this would > offer insufficient flexibility and configurability - as was already raised > in previous discussions on this issue. > > > > In the ticket, Shai described a few particular goals for this feature: > > > > - Informing the user of the various password requirements: this is > possible by each validator providing a description, which can be dependent > on it's configuration, of it's requirements. Independent sentences from > different validators are now concatenated, an approach which will not > always yield the prettiest language. > > - Allowing policies to chain together smoothly: multiple validators can > be run sequentially, stopping after the first failure. > > - Provide flexibility for complex requirements (some may include their > own models): this is entirely possible within the design. > > - Backwards compatibility: the default setting is to have no validators, > which means no change and no modifications in help text. I do suggest we > include some reasonable defaults in the standard project template. > > - Javascript validation assistance or HTML5 support: not implemented > currently, but this could be added in a similar way as help texts. > > - Prevent using email, username or other user attributes as (part of) > passwords: where possible, the user object is passed to the validator. > There's a (not pretty) example of this in the PR. > > - Prevent reuse of old passwords: it is possible in the design for a > validator to store all passwords it saw. I have doubts on whether this > would be a good approach though. > > > > So I think this design makes it simple to have sane defaults for new > projects, extensive configurability while keeping simple scenarios simple > to configure, and easy extensibility with third party password validators > (zxcvbn comes to mind). I'd love to hear any feedback and ideas you may > have. > > > > Erik > > > > > > [1] https://code.djangoproject.com/ticket/16860 > > [2] https://github.com/django/django/pull/4276 > > > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers (Contributions to Django itself)" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to django-develop...@googlegroups.com <javascript:>. > > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > > Visit this group at http://groups.google.com/group/django-developers. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/DC7E0945-5FC9-43CA-97C5-FE5872A05DE1%40solidlinks.nl. > > > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/eac7e7a6-df0b-4d64-900b-3bcd37e64424%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
