Password validation in Django revisited

[Erik Romijn]

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

[Raphael Michel]

Hi Erik,

Am Sun, 8 Mar 2015 15:47:27 +0100
schrieb Erik Romijn <ero...@solidlinks.nl>:

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

I really like this a lot, both the idea of the ticket and the way
you're proposing to implement it.

However, I'm not quite sure whether I like the style you chose to pass
constructor arguments in the PASSWORD_VALIDATORS setting you proposed. I
believe it might be worth considering to design the PASSWORD_VALIDATORS
setting in a similar fashion to the new TEMPLATES setting.

I understand why you chose this style and it might really be the best
way to do this one thing, but I fear it adds complexity because it
behaves differently than all other settings variables and thus makes it
harder to remember how Django's settings work.

Raphael

[charettes]

Hi Erik,

This looks promising. I like how the validators can be chained and the whole simplicity of the patch.

Here's some comments I also left on the PR;

1. I think the settings should be name AUTH_PASSWORD_VALIDATORS since it's being use by the auth contrib app;
2. I would avoid mixing the backend and validators terminology. e.g `get_password_validators` sounds like a more consistent name then `get_password_backends`;
3. I would either make `help_text` a property of rename the method to `get_help_text`.

Like Raphael I also think we should avoid introducing a new way of defining settings. I suggest we use a list of path to instances of password validators instead:

AUTH_PASSWORD_VALIDATORS = [
    'django.contrib.auth.password_validators.min_eight_chars_validator',
]

And document MinimumLengthPasswordValidator so you can create your own instances and point the setting to it.

Simon

[Erik Romijn]

Hello Simon and Raphael,

Thanks for your input. I’ve adopted all your suggestions into the PR.

For the settings, I’ve now mirrored the TEMPLATE structure. I entirely agree that adding a new structure is an unnecessary burden on our users. I’m not too fond of Simon’s suggestion, as I’d like to have some basic configurability for each validator, without having to create an instance and store it somewhere yourself. That is still an option for advances customisation.

Erik

-- 
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/494039b5-c06b-4afc-aaf3-0705db37d13e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aymeric Augustin]

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.

> --
> 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/DC7E0945-5FC9-43CA-97C5-FE5872A05DE1%40solidlinks.nl.

[Collin Anderson]

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

[Shai Berger]

Hi Erik and all,

The approach, indeed, seems fine, which is far from trivial. Some details, of
course, still need to be worked out. I like Aymeric's suggestion re help_text
-- I would take that one step further and allow every validator to give its
own list of requirements.

I have one "devil's advocate" suggestion to consider: Instead of the
validators, let's allow setting the password field. In principle, this should
give us almost the same flexibility, and open some more possibilities (e.g.
widgets that take gesture passwords like some mobile screen-lockers use; using
a composite field to handle confirmation, instead of two separate fields). This
is a completely halfbaked idea, but I thought I'd better put it out here.

Also, there's one point I need to correct:

On Sunday 08 March 2015 16:47:27 Erik Romijn wrote:
>
> In the ticket, Shai described a few particular goals for this feature:
>

I was the last to edit that list, but most of it was actually written by Paul
Mcmillan.

Have fun,
Shai.

[Josh Smeaton]

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

[Tino de Bruijn]

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

--

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.

[Erik Romijn]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANQFsQATUqV1CfsnAdjrvAQgHs0eQ-zx7pVC%2Bg9KvDiQ7mFbYQ%40mail.gmail.com.

[Erik Romijn]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/24FEB9D0-03ED-4CD6-81D4-E5A981C6BFE3%40solidlinks.nl.

[Alex Becker]

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.

[Marc Tamlyn]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20e86482-be46-4dc8-b363-313eecafa926%40googlegroups.com.

[Alex Becker]

With the PR merged, password validation applies to the SetPasswordForm and the password changing forms, but not to the UserCreationForm or to the creation of superusers. Is there a reason not to apply validation to these as well?

Alex Becker

On Saturday, April 11, 2015 at 5:35:03 AM UTC-5, Erik Romijn wrote:

[Carl Meyer]

On 06/21/2015 06:17 PM, Alex Becker wrote:
> With the PR merged, password validation applies to the SetPasswordForm
> and the password changing forms, but not to the UserCreationForm or to
> the creation of superusers. Is there a reason not to apply validation to
> these as well?

Certainly makes sense to me to add validation to both of these. I missed
it in review. Erik, is there a reason you didn't, or was it just an
oversight?

Carl

[Erik Romijn]

Hi Alex, Carl,

No reason at all. I hadn’t even realised there was such a form. It seems
sensible to add it (along with a test), but I don’t have time to make the
patch currently.

Erik

[Alex Becker]

Hi Erik,

I've written such a patch, which also fixes an html escape bug and adds validation to the auth management commands.

The pull request is here.

Sincerely,

Alex

[Markus Holtermann]

Hey,

while I like the idea of having the validation in all places to not forget one that might be user facing, I was surprised by the fact that the validation also happens in dev environments when you create the superuser (this whole mail applies to the changepassword command, too):

$ python manage.py createsuperuser
Username (leave blank to use 'markus'):
Email address: ********
Password:
Password (again):
This password is too short. It must contain at least 8 characters.
Password:
Password (again):
The password is too similar to the email address.
Password:

This is a bit annoying for me, given that I normally use "markus" or "admin" as username and password for the superuser and u1:u1, as username:password combination for additional users.

There are a few solutions to that behavior I'd like to see revisited for 1.9:

1. Disable password validation when DEBUG=True -- I don't think we really want that
2. Don't have password validation for createsuperuser/changepassword: I personally don't see the benefit for that in the command anyways.
1. In production environments I would expect the admins having access to the management command to know their regulations (after all, they need to configure them) and to know what good passwords are. 
2. As somebody who is able to run the "createsuperuser" command I figure I can also run "shell", giving me unlimited access to the password field of users, allowing me to set a password that doesn't match the requirements.
3. It breaks backwards compatibility with tools like Expect (https://en.wikipedia.org/wiki/Expect -- yes, I had to use that in the past)
3. Disable validation when passing --no-validate or --no-validate-password to createsuperuser, though this is still backwards incompatible and a lot to type -- I'd better of with having a valid password -- or the other way around, passing --validate / --validate-password, but this feels pointless

My preference is definitely (2), though I'm sorry for not bringing this up earlier when the issue was created.

The original issue: https://code.djangoproject.com/ticket/25089

Respective PR: https://github.com/django/django/pull/5073

Cheers,

/Markus

[Aymeric Augustin]

Hello,

Indeed, this will be annoying for development.

I don’t find the “admins don’t need rules, they know what they’re doing” argument compelling. The cobbler children’s go barefoot… Besides, if admins know the rules, having validation enabled won’t hurt :-)

I’m in favor of implementing an escape hatch when DEBUG = True:

- either downgrade the message to a warning and proceed

- or ask the user if they want to proceed with the invalid password (--no-input would skip this step and proceed silently)

-- 

Aymeric.

-- 
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/9860adf7-b0b3-492d-b8a0-f08c7b85b587%40googlegroups.com.

[Markus Holtermann]

Hey Aymeric,

I think I'd prefer "downgrade the message to a warning and proceed" for DEBUG=True and list all validation errors, much like for forms. Sticking to the current implementation for DEBUG=False is fine with me. For example:

$ python manage.py createsuperuser

Username (leave blank to use 'markus'):

Email address: ********

Password:

Password (again):
The passwords do not match.

Password:

Password (again):

You used a password that doesn't fulfill all validation requirements:
  - This password is too short. It must contain at least 8 characters.

  - The password is too similar to the email address.

Superuser successfully created

Cheers,

/Markus

[Aymeric Augustin]

Well, I would prefer asking for confirmation ;-) but not enough to write the code myself.

-- 

Aymeric.

-- 
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/470bba48-2695-405e-bdf4-88b66373a323%40googlegroups.com.

[Wim Feijen]

Hi Markus and Aymeric,

In my opinion, it is very safe and consistent to use password validation in all instances and places. It definitely prevents people from using admin/admin and markus/markus as a login, which sounds safe to me. 

If you don't want that, you can change the validators depending on DEBUG in your settings; or disable them in your local_settings. In addition, you can change the password using the shell as you suggested.

I don't agree that we should allow unsafe passwords in some cases and I don't think we should. 

I apologize for differing in opinion,

Wim

-- 

Aymeric.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsub...@googlegroups.com.

[Unai Zalakain]

Hi Wim,

>In my opinion, it is very safe and consistent to use password
>validation in
>all instances and places. It definitely prevents people from using
>admin/admin and markus/markus as a login, which sounds safe to me.
>
>If you don't want that, you can change the validators depending on DEBUG in
>your settings; or disable them in your local_settings. In addition, you can
>change the password using the shell as you suggested.

I think using admin/admin or company/company at the development stage is
quite a common and widely-used pattern. Making the developer use strong
passwords or going through the hassle of deactivating password
validators seems a bit too much waste of time for little or no gain to
me.

I would even dare to say I'm totally against activated-by-default
password validators. I think it should be a decision the developers take
consciously, as it again adds just more overhead (which Django surely
doesn't need).


--
unai

[Florian Apolloner]

On Monday, September 7, 2015 at 5:37:03 PM UTC+2, Unai Zalakain wrote:

I would even dare to say I'm totally against activated-by-default
password validators.

Security comes first, so the should stay on by default.
 

I think it should be a decision the developers take
consciously, as it again adds just more overhead (which Django surely
doesn't need).

I doubt the overhead there is big, got any numbers to back up that claim? Also if it adds too much overhead for you, feel free to disable them.

Cheers,
Florian

[Marc Tamlyn]

I agree with Aymeric and Markus that createsuperuser should not validate strength of passwords when DEBUG is on. Having to use a secure password for development/test accounts is an unnecessary level of interference for users.

I agree its safer to prevent using admin/admin in production and this is a good thing, but there's no reason to prevent this for development. In fact, I'd argue enforcing it for development will encourage teams to have a "standard" secure password for their sites, which is also used in production. By allowing admin/admin in development, and enforcing something better in production we are more helpfully enforcing best practice.

--

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/e653f37d-dc81-430b-87c4-47477bd971d9%40googlegroups.com.

[Unai Zalakain]

>Security comes first, so the should stay on by default.

True, security comes first, but from the philosophical point of view, I
wouldn't like forcing by default any particular password policy to the
users. If I understood it right, it isn't just a simple warning that
says your password is too weak and lets you continue: it blatantly
refuses to set that password for you. That is what I don't like.

Some other related questions also come to my mind: What exactly are we
considering a secure password? Why not leave the validator list empty by
default and document the feature on the security checklist, with the
rest of deployment-related features that aren't on by default?

Don't take me wrong, I *do* think this is a great feature, but it should
be the developers choice to turn it on.

--
unai

[Shai Berger]

On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
> I agree with Aymeric and Markus that createsuperuser should not validate
> strength of passwords when DEBUG is on. Having to use a secure password for
> development/test accounts is an unnecessary level of interference for
> users.
>
> I agree its safer to prevent using admin/admin in production and this is a
> good thing, but there's no reason to prevent this for development. In fact,
> I'd argue enforcing it for development will encourage teams to have a
> "standard" secure password for their sites, which is also used in
> production. By allowing admin/admin in development, and enforcing something
> better in production we are more helpfully enforcing best practice.
>

+1.

Shai.

[Podrigal, Aron]

+1

[Tim Graham]

I think the simplest solution could be to remove the default list of AUTH_PASSWORD_VALIDATORS that have been added to the project template settings file and let the user add it to their own production settings instead. Do you think this reduces the usefulness of the feature? We could add a deployment check for an empty AUTH_PASSWORD_VALIDATORS as an alternate way of encouraging its use.

[Josh Smeaton]

I don't think removing the default list from the template is the right idea. We'd be sacrificing some production users that don't go through security options on deployment checklists to better support development environments where the security issue (probably) isn't present. I do think we need some kind of solution though, because I don't want these validators in development either. Personally, I have no issue with adding a SETTING=[] to my local_settings. It would be nicer to drive a solution based on DEBUG though.

Cheers

[Podrigal, Aron]

I started using django-classy-settings and it works very well for me.

--

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/1aba1352-89ba-4cfe-a789-77430c504026%40googlegroups.com.

[Tim Graham]

The extra complexity of varying validation logic based on DEBUG doesn't seem quite right to me, but I guess I won't oppose it if that's the consensus.

Another option could be this in the generated settings file:

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    ...
] if not DEBUG else []

Of course this depends on whether or not you expect other places like the admin's change password form to do validation in debug mode.

[Josh Smeaton]

I agree with you that the extra implementation complexity is probably not right or at least not worth the gain, especially when it comes to things like testing. I take back what I said about switching behaviour based on DEBUG. You should also be able to run validators in DEBUG if you choose to. I don't think there's an issue with requiring users to explicitly disable the validators in their local settings file if they want to use insecure passwords for development.

I don't mind the AUTH_PASSWORD_VALIDATORS = [ .. ] if not DEBUG else [] pattern. Perhaps it's worth just documenting that pattern as a note for users to use themselves?

[Unai Zalakain]

>I don't think removing the default list from the template is the right
>idea. We'd be sacrificing some production users that don't go through
>security options on deployment checklists to better support development
>environments where the security issue (probably) isn't present. […]

I don't think there's a risk of users overlooking the feature if we add
a check to the checks framework.

--
unai

[Florian Apolloner]

On Monday, September 7, 2015 at 7:30:58 PM UTC+2, Unai Zalakain wrote:

Some other related questions also come to my mind: What exactly are we
considering a secure password?

Whatever we consider "secure" at this point.

 

Why not leave the validator list empty by
default and document the feature on the security checklist, with the
rest of deployment-related features that aren't on by default?

Cause noone reads docs and this is not really deployment related imo.

Don't take me wrong, I *do* think this is a great feature, but it should
be the developers choice to turn it on.

When it comes to security I rather have devs turn it off, in the end this will provide a safer behavior…

[Carl Meyer]

On 09/07/2015 06:31 PM, Tim Graham wrote:
> The extra complexity of varying validation logic based on DEBUG doesn't
> seem quite right to me, but I guess I won't oppose it if that's the
> consensus.

I'm strongly -1 on anything that automatically turns off password
validation everywhere based on DEBUG, especially if there's no way to
override. Django should always be _very_ cautious about introducing more
automatic variance in behavior between development and production modes.
(Not to mention that I don't think DEBUG should be used as a proxy for
"development vs production" anyway, but that ship sailed a long time
ago.) If people want this behavior, they should do it themselves in
their settings file.

My favorite option is for the createsuperuser command specifically (and
nothing else) to implement password validation as a confirm dialog
rather than a hard block. If your password fails validation, it tells
you how and asks you to confirm that you really want to use that
password. This makes sense to me because the createsuperuser command
(unlike any site web UI) can only ever be used by someone who would also
have the ability to set their password directly via shell if they want.
So it's good to remind them of the validation fail, but there's no
reason to make their life difficult.

> Another option could be this in the generated settings file:
>
> AUTH_PASSWORD_VALIDATORS = [
> {
> 'NAME':
> 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
> },
> ...
> ] if not DEBUG else []
>
> Of course this depends on whether or not you expect other places like
> the admin's change password form to do validation in debug mode.

I'm -0.5 on this. I don't think varying behavior based on DEBUG is
really something we should push that strongly. People can still do it if
they want, of course.

Carl

[Unai Zalakain]

>Cause noone reads docs and this is not really deployment related imo.

What if the checks framework warned it?


--
unai

[Florian Apolloner]

On Tuesday, September 8, 2015 at 5:18:32 PM UTC+2, Unai Zalakain wrote:

>Cause noone reads docs and this is not really deployment related imo.
What if the checks framework warned it?

If it is empty? fine for me, but the default has to stay with enabled ones…