Re: Password validation in Django revisited

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… -- You received this messag

Re: Password validation in Django revisited

Cause noone reads docs and this is not really deployment related imo. What if the checks framework warned it? -- unai -- 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 st

Re: Password validation in Django revisited

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 DE

Re: Password validation in Django revisited

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 documen

Re: Password validation in Django revisited

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 t

Re: Password validation in Django revisited

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.

Re: Password validation in Django revisited

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_v

Re: Password validation in Django revisited

I started using django-classy-settings and it works very well for me. On Sep 7, 2015 8:04 PM, "Josh Smeaton" wrote: > 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 che

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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 depl

Re: Password validation in Django revisited

+1 On Sep 7, 2015 4:56 PM, "Shai Berger" wrote: > 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

Re: Password validation in Django revisited

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 ag

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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, a

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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 dependi

Re: Password validation in Django revisited

Well, I would prefer asking for confirmation ;-) but not enough to write the code myself. -- Aymeric. > On 5 sept. 2015, at 10:54, Markus Holtermann wrote: > > Hey Aymeric, > > I think I'd prefer "downgrade the message to a warning and proceed" for > DEBUG=True and list all validation err

Re: Password validation in Django revisited

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 u

Re: Password validation in Django revisited

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 es

Re: Password validation in Django revisited

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 m

Re: Password validation in Django revisited

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 On Friday, June 26, 2015 at 3:19:30 AM UTC-5, Erik Romijn wrote: > > Hi Alex, Carl

Re: Password validation in Django revisited

Hi Alex, Carl, On 22 Jun 2015, at 02:43, Carl Meyer wrote: > 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 rea

Re: Password validation in Django revisited

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 s

Re: Password validation in Django revisited

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, Eri

Re: Password validation in Django revisited

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 wrote: > Hi Erik, > >

Re: Password validation in Django revisited

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 defa

Re: Password validation in Django revisited

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 f

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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 Monda

Re: Password validation in Django revisited

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

Re: Password validation in Django revisited

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 h

Re: Password validation in Django revisited

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 mix

Re: Password validation in Django revisited

Hi Erik, Am Sun, 8 Mar 2015 15:47:27 +0100 schrieb Erik Romijn : > 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 n

Password validation in Django revisited

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 sufficien