Password policy obsolete

[micheelengronne]

The current password policy and complexity system is obsolete.

as stated here:

• https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/
• https://pages.nist.gov/800-63-3/sp800-63b.html#appA
• https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret
• https://www.welivesecurity.com/2017/05/03/no-pointless-password-requirements/
• https://www.intellisuite.com/blog/2019-password-policy-best-practices
• https://ldapwiki.com/wiki/Password%20Character%20Composition

rules involving to force uppercase, lowercase, special characters, etc... are useless against attacks and counter-productive.

It would be better to enforce a minimal length and use a password strength checker based on entropy like https://github.com/dropbox/zxcvbn.

[zeripath]

In [SECURITY] set PASSWORD_COMPLEXITY=off and set MIN_PASSWORD_LENGTH=10

AFAIU There is no recommended NIST compliant entropy checker.

[micheelengronne]

That's what I did. I just suggest to remove the PASSWORD_COMPLEXITY option totally.

It is misleading and gives a false sense of security.

There is no recommended NIST compliant entropy checker, zxcvbn was just a proposal.

[lafriks]

In some countries there are government rules for software to be used in government organizations it has to support password complexity rules. Also internal company policies might require it so I don't see why this should be removed

[zeripath]

I do wonder if it should be set off by default though - with the default MIN_PASSWORD_LENGTH set higher - so that we have the system in a more correct default position. (@micheelengronne I too dislike the PASSWORD_COMPLEXITY settings.)

In terms of using zxcvbn - the difficulty is that it requires downloading large dictionaries: https://github.com/dropbox/zxcvbn#script-load-latency . I've looked at adding it before but realised it would be a bigger job than a 5 minute task.

[mrsdizzie]

I think setting PASSWORD_COMPLEXITY=off is a better default (I also really dislike it), I agree with all the comments on why it is silly but seems fine to keep it as an option for people that do need some very particular requirement as described above.

I don't think anybody who doesn't like it will even notice it is there if off by default.

Also working at a mail host and seeing many compromised passwords I can say that incorporating https://haveibeenpwned.com/API/v3 into the password selection process has probably been the most helpful and stopping users from choosing something compromised and forcing a more unique/random value and could be nice to have optional support for that at some point for general password concerns

[micheelengronne]

agreed with you @zeripath and @mrsdizzie. I think using the dictionaries option of zxcvbn is useless as it is not well maintained and only available for english language (and I can tell as a french speaker that most common broken passwords in french are not the same than in english).

I think Troy Hunt's HaveIbeenPawned is a better solution than dictionaries. But it opens new problems:

• an external dependency to a centralized closed-source system
• jurisdiction problems as HaveIbeenPawned is subject to australian law that is in potential conflicts over data regulations with EU (for instance)

So maybe, we can have 2 options to add in the app.ini:

• ENABLE_ZXCVBN: replace PASSWORD_COMPLEXITY with zxcvbn without dictionnaries
• ENABLE_HIBP: add HaveIbeenPawned to that

[guillep2k]

I like the HIBP API alternative, and I don't see a problem if it's an optional feature, jurisdictional or otherwise. I'd too remove the default "on" of password complexity.

As for ZXCVBN, the size of it makes it less appealing to me, and the dictionary maintenance is also a minus. Perhaps the dictionary is something that can be downloaded/maintained by the user?