Password policy obsolete #5284

Closed
opened 2025-11-02 06:20:13 -06:00 by GiteaMirror · 7 comments
Owner

Originally created by @micheelengronne on GitHub (Apr 22, 2020).

The current password policy and complexity system is obsolete.

as stated here:

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.

Originally created by @micheelengronne on GitHub (Apr 22, 2020). 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.
GiteaMirror added the type/proposal label 2025-11-02 06:20:13 -06:00
Author
Owner

@zeripath commented on GitHub (Apr 22, 2020):

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

AFAIU There is no recommended NIST compliant entropy checker.

@zeripath commented on GitHub (Apr 22, 2020): In `[SECURITY]` set `PASSWORD_COMPLEXITY=off` and set `MIN_PASSWORD_LENGTH=10` AFAIU There is no recommended NIST compliant entropy checker.
Author
Owner

@micheelengronne commented on GitHub (Apr 22, 2020):

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.

@micheelengronne commented on GitHub (Apr 22, 2020): 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.
Author
Owner

@lafriks commented on GitHub (Apr 22, 2020):

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

@lafriks commented on GitHub (Apr 22, 2020): 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
Author
Owner

@zeripath commented on GitHub (Apr 22, 2020):

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.

@zeripath commented on GitHub (Apr 22, 2020): 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.
Author
Owner

@mrsdizzie commented on GitHub (Apr 22, 2020):

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

@mrsdizzie commented on GitHub (Apr 22, 2020): 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
Author
Owner

@micheelengronne commented on GitHub (Apr 22, 2020):

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
@micheelengronne commented on GitHub (Apr 22, 2020): 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
Author
Owner

@guillep2k commented on GitHub (Apr 24, 2020):

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?

@guillep2k commented on GitHub (Apr 24, 2020): 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?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#5284