Hi Brad,
I appreciate no one has replied here for some time, and your ticket was closed rapidly after your work creating the code. I can imagine it might be a bit frustrating.
Thanks for trying to improve Django. I see you've submitted some other PR's since, thanks for that work.
My thoughts on the password validators:
First, I'd like to say there has probably not been much thought on the issue. The Django fellows, and everyone on this mailing list, have a lot on their plates. The fellows have probably defaulted to "no" on these feature request tickets simply to keep Django at a manageable size. We are conservative in adding new code because it needs maintaining forever (or however long Django will live!). You're right the API surface area is small and stable, but new features all add up.
Also the suggestion to create a third party package has a precedent. The Django ecosystem is maybe 10,000x more code than Django core - core simply can't contain the long tail. A number of good ideas in Django have actually been third party packages first, for example Andrew Godwin's South which evolved into Django Migrations.
Additionally, releasing a package means that users (yourself included!) can use the features *today*, rather than in 9 months' time when the next Django release comes out. (...or 5 years time when your project actually gets upgraded.)
Second, I would like to consider the password validation more closely. When I think about the topic these days, I point to the NIST guidelines. They went through a big change in 2016. I saw this reported a couple times in security media - it was hailed as a forwards step towards more sane password management across the industry. Here's an article summarizing them in non-governmental language:
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ .
in general the guidelines represent a move away from the attitude you spirit you quoted in your PR: "more validation is almost always better"
I think the guideline against composition rules would be against the first three validators you suggested in #30442, to quote the article:
No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”
Additionally, although the article doesn't mention it, I found in the document NIST.SP.800-63b Appendix A a warning against trying to measure entropy. This would argue against adding the entropy validator suggestions in #27568 and #30442:
Complexity of user-chosen passwords has often been characterized using the information theory
concept of entropy [Shannon]. While entropy can be readily calculated for data having
deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult
and past efforts to do so have not been particularly accurate. For this reason, a different and
somewhat simpler approach, based primarily on password length, is presented herein.
On the other hand, there is a recommendation to check against databases of known crackable passwords. This would lead us to the pwned passwords validator suggested in #30100 as a more powerful version of Django's built-in CommonPasswordValidator. There are a couple reasons I can see *not* to add it to Django core though:
- The validator relies on a third party web service. If the service changes after a version of Django goes out of support, the validator will stop working and no future release of that version of Django will be issued to fix it.
- There is already a package implementing this validator, by Django core team member James Bennett: https://pypi.org/project/pwned-passwords-django/ . I think packages maintained by James are of a quality only second to Django itself.
That said, whilst it might be "more sane" to move to the NIST guidelines, Django can adopt some pragmatism. We developers can be forced to implement validation to fit in with some regulatory guidelines. I think if there was good evidence that a validator would be required by a large number of Django projects, I believe it wouldn't be out of place in Django core. On the other hand, a great way to prove this utility is to make a third party package that becomes popular :)
Looking at Django Packages, I found only one third party package explicitly offering password validators:
https://djangopackages.org/packages/p/django-password-validators/ . And for its name, it only offers one validator at current, UniquePasswordsValidator . It seems there isn't much state of the art for password validators right now - but perhaps they're not a particularly interesting topic for third party package development!
To conclude, I think you asked a number of good questions around what could constitute grounds for adding password validators (or any features) to Django core. I admit I haven't addressed them directly, but I hope I've approached them enough indirectly. If you have any more thoughts, please do respond!
Thanks,
Adam