Password Policy Adherence. Cannot use the passwords used before

[Simon A]

Hello,

I'm trying to make my django app follow this policy, that the user cannot user his/her last 6 passwords that were already used before.

I tried using the django-password-policies library but I'm getting a lot of errors. I think it's not compatible anymore with the current version of django.

I was wondering if there is a way that I can implement this requirement from scratch so I can get the whole picture.

If you could, kindly share some references that I can use to start with this.Or at least point me to the topics that I need to look into.

Thank you,

Simon

[Jason]

I haven't found anything like a drop-in replacement, but this should be fairly simple for you to do.

when a password changes, the hash of the former password is stored in a different table with a reference to the user and the timestamp.  when a new password is entered in as a reset, you compare the last 6 passwords ordered by timestamp and see if any match.

[James Bennett]

I'm going to suggest you step back and consider whether the policies you want to implement are good policies. A good, solidly-researched set of recommendations is NIST SP800-63B:

https://pages.nist.gov/800-63-3/sp800-63b.html

In particular, NIST suggests the following:

* Do not use a policy which automatically "expires" passwords and forces users to change them periodically. Only force a password change when you have evidence that a password has been compromised.

* Do not try to impose artificial "complexity" rules (like requiring a mix of uppercase/lowercase, numbers and symbols).

* When a user changes their password, compare it against lists of known-compromised passwords.

Forcing users to change their passwords on a set schedule just encourages them to choose weak passwords that are easy to remember. If you force me to change my password every three months, for example, here's what I'll do:

* P@ssword!2019_1

* P@ssword!2019_2

* P@ssword!2019_3

* P@ssword!2019_4

These passwords are all different from each other, and they each contain at least one uppercase and one lowercase letter, at least one number and at least one symbol. They're also terrible passwords that would probably get cracked within minutes, if not seconds, by any good automated cracker.

That's a year's worth of passwords, each of which is different from the last, each contains one 

[Matthew Pava]

I completely support this NIST policy, James.  Unfortunately, the PCI Security Standards Council does not support this policy at this time.  In order for a company to be PCI compliant, users must change their passwords every three months.  PCI compliance is essential for companies to adhere to when they are processing credit cards.  There are ways around the requirements; companies could basically out-source credit card processing to other companies such as Stripe or Square, but they need to know what they are doing to maintain compliance.

 

https://www.pcisecuritystandards.org/documents/Payment-Data-Security-Essential-Strong-Passwords.pdf?agreement=true&time=1549638814227

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAL13Cg9Xi7QdCCffqROi_FjLzKimtWYBR%3DusMxf6ihf_E6%3D-9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Simon A]

@Jason, yes I believe I do need to research further when that action happens. the point where the password is hashed and stored in the User table. I'll continue to work on it.

@James, currently the requirements are non debatable for us developers in the company. The security team implemented the guidelines and by any means, they have to be implemented. (Even though the company apps don't even follow the policies!) I believe it's just additional work for developers, and makes the development time longer which equates to less value to customers. But I do appreciate the points you provided. When I have the chance to have a discussion with the security team, I will definitely bring up these points.

You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/RXEq0nWCPeQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7d7e9de09028498e8fca89973db6484f%40iss2.ISS.LOCAL.

For more options, visit https://groups.google.com/d/optout.

--

Kind Regards,

Simon Arriola

[Simon A]

Hi guys,

Please correct me if my thought process is wrong. 

Here is what I am trying to achieve, in order for me to save the password generated before saving the new password to the system, I have to somehow override the existing process. Which is by subclassing the PasswordChangeView. As I check the available methods that I can override, I got more confused because none of these methods seem to retrieve the password from the form, then hash it. then store the hashed password in the User's profile. Where does this actually happen? 

I looked at here http://ccbv.co.uk/projects/Django/2.1/django.contrib.auth.views/PasswordChangeView/ and http://ccbv.co.uk/projects/Django/2.1/django.contrib.auth.views/PasswordContextMixin/ to identify where does the process of hashing and saving happen but it just doesn't make sense to me at the moment. I'm sorry I'm not trying to be spoon fed here but just a bit lost.

Any feedback would be appreciated.

Thank you,

Simon

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

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAL13Cg9Xi7QdCCffqROi_FjLzKimtWYBR%3DusMxf6ihf_E6%3D-9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/RXEq0nWCPeQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7d7e9de09028498e8fca89973db6484f%40iss2.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

[Jason]

ClassyCBV doesn't contain everything in django, so that is probably related to your confusion.

In classycbv PasswordChangeView's attributes, you can see 

form_class = <class 'django.contrib.auth.forms.PasswordChangeForm'>

which is what is called in PCV's Post handler

Now, that form is defined here, which inherits from SetPasswordForm.  There's two methods inside that class, save, and clean_new_password2

Since these forms inherit from forms.Form, they all inherit is_valid, which has this comment:  

"""Return True if the form has no errors, or False otherwise."""

So, what you'll need to do is override that `is_valid` method in your custom Form class to do the work for you.

[Simon A]

Hi Jason,

Thank you for  your response, really appreciate the help. I was working on your suggestion but then stumbled across django-password-validators which seems to do the required task for me. For now I will go with this one. But I will surely include the github for django when learning things to better understand how some magis work.

Kind Regards,

Simon Arriola

[Jason]

Sometimes going through the source code is the easiest way to figuring out the problem :-)

[Simon A]

Yes that's very true. I guess I acquired a phobia for diving into the source code because of my first programming language (J**A) because it felt like I was reading cryptic stuff. But not with Python.