This seems like a great example of something which can live as an external package, and you document how to use it with `AUTH_PASSWORD_VALIDATORS`. You could add a minimum entropy parameter as an option which can be passed in the dict.
On 17 June 2015 at 03:38, Alex Becker <alcubec...@gmail.com> wrote: > Hi Erik, > > I've done some work on pattern-based password validation in python, > something intermediate in complexity between these validators and zxcvbn. > The rough version is on github[1]. I was thinking of turning this into a > password validator for django, one which would not be turned on by default. > Thoughts? > > Alex Becker > > [1] https://github.com/alexbecker/password-strength > > Disclaimer: this is my first post to django-developers or any other oss > mailing list for that matter. I apologize in advance for any breach of > protocol. > > On Saturday, April 11, 2015 at 5:35:03 AM UTC-5, Erik Romijn wrote: >> >> Hi all, >> >> The PR [1] has now been extended taking much of the feedback into account >> and adding docs and tests. I have also added a validator for common >> passwords, based on a list of 1000 most common passwords. So I think the PR >> is ready for another round of review - I’m sure there is still room for >> improvement. Only current open task is to add release notes. >> >> We now have three validators, all enabled by default in new projects: the >> common password validator, a validator that simply checks whether the >> password meets a minimum length, and one that compares the password to the >> user’s attributes, such as their name or e-mail address. The latter has >> limits in it’s comparison - a more thorough method is provided, for >> example, by zxcvbn [2]. However, I think vendoring a Python port of zxcvbn >> is a little too much - I do intend to create a third party package with a >> validator that ties to zxcvbn. >> >> There was a suggestion for a character class validator, e.g. requiring >> that the password contains digits or uppercase characters. I’m not very >> fond of that. Although quite common, I have strong doubts about whether it >> actually improves passwords: my impression is that requiring users to add a >> number will often mean they’ll add a 1 to the end, and requiring them to >> add an uppercase character will mean they uppercase the first character. If >> that is true, such a requirement would actually reduce password entropy, as >> one could assume that the last character of a password is almost always 1, >> etc. Unfortunately, I haven’t been able to find any research to support >> that (or the contrary), so I can’t back this up with anything solid. >> >> For clarity, by default we do not enable any validators in existing >> projects when they upgrade, as that would be breaking backwards >> compatibility. >> >> Erik >> >> [1] https://github.com/django/django/pull/4276 >> [2] https://github.com/dropbox/zxcvbn >> >> On 14 Mar 2015, at 15:26, Erik Romijn <ero...@solidlinks.nl> wrote: >> >> Hi all, >> >> Thanks for all the feedback. Good to see this seems to be heading in the >> right direction. The suggestions make sense to me and I’ll work on those. >> >> There were two particular design suggestions: instead of tying the >> validator to the password field, tying this to the authentication backend, >> which would prevent having to add a setting, and allow different security >> requirements for different backends. Another suggestion was to add >> configurable password fields instead, which could also include other >> functionality. >> >> My concern with tying the validator to the auth backend instead, is that >> it would mean there is absolutely no way to circumvent the validation, >> whereas in the current scenario I’ve intentionally not included validation >> in User.set_password() by default - but only in the user-facing elements. I >> think it will be easier to get wider adoption of password validation, if we >> still leave an opportunity open to avoid it in special cases. Also, I’m not >> sure whether we could still easily and cleanly provide the appropriate help >> text to the user. >> >> If someone would want validation that depends on the auth backend, this >> is possible with undocumented APIs. If my memory serves me right, the user >> object that the validator has access to will have an attribute that >> identifies the backend used to authenticate the user. The validator could >> make different choices based on that, or even call a method on a backend. >> That’s not with a currently documented API though. >> >> Replaceable password fields are themselves interesting, but I think it >> would be too limited for password validation in general. A specific wish >> was to also be able to tie validation into a REST API, for example. The >> current validator design allows trivial integration of a validator into >> absolutely anything. Custom password fields are already not too hard - all >> you have to do is create your own form, override the password fields and >> pass that form to the appropriate views. It’s not even necessary to write >> your own views. We could make that process simpler if the other benefits of >> custom password fields are relevant enough, but I don’t think they’re the >> best design for the validation problem. >> >> Erik >> >> On 11 Mar 2015, at 09:52, Tino de Bruijn <tin...@gmail.com> wrote: >> >> Hi Erik, I like the way this is going! >> >> I do want to emphasise the point that Josh made: you have to be able to >> aggregate all ValidationErrors, otherwise things can become quite >> frustrating. (Try to change your Skype password and you know why...) >> >> Tino >> >> On Wed, Mar 11, 2015 at 1:44 AM, Josh Smeaton <josh.s...@gmail.com> >> wrote: >> >>> Great stuff Erik. This will greatly simplify how we validate passwords! >>> >>> One thing I'd like to note is that it is extremely frustrating when a >>> form fails validation with an error message, you fix that particular >>> problem, and you're given the next error message. Ideally, all validators >>> would run and spit out all of the error messages in one go. Then the user >>> is given a chance to correct all problems at once rather than a submit and >>> hope game. I took a look at the implementation and I don't think this is >>> supported. Would it be possible to aggregate all of the ValidationErrors? >>> >>> Cheers >>> >>> >>> On Monday, 9 March 2015 01:48:00 UTC+11, Erik Romijn wrote: >>>> >>>> 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. >>> To post to this group, send email to django-d...@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/3a0b87ad-5073-4af1-8a7a-cd91705e287a%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/3a0b87ad-5073-4af1-8a7a-cd91705e287a%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> 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-develop...@googlegroups.com. >> To post to this group, send email to django-d...@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/CANQFsQATUqV1CfsnAdjrvAQgHs0eQ-zx7pVC%2Bg9KvDiQ7mFbYQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CANQFsQATUqV1CfsnAdjrvAQgHs0eQ-zx7pVC%2Bg9KvDiQ7mFbYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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-develop...@googlegroups.com. >> To post to this group, send email to django-d...@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/24FEB9D0-03ED-4CD6-81D4-E5A981C6BFE3%40solidlinks.nl >> <https://groups.google.com/d/msgid/django-developers/24FEB9D0-03ED-4CD6-81D4-E5A981C6BFE3%40solidlinks.nl?utm_medium=email&utm_source=footer> >> . >> 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/20e86482-be46-4dc8-b363-313eecafa926%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/20e86482-be46-4dc8-b363-313eecafa926%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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/CAMwjO1E-o61EzT_YffgwTSj8YeHvQzftaKeTkbMektng%3DvUXUA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
