[Enhancement]: Password Policy

[theniwo]

We need administrative settings to control the strenth of a password.

Currently users can set their password to anything unsafe.

These requirements should be enableable

• A-Z
• a-z
• 0-9
• Special characters
• Password length
• No reuse of passwords

[DieselTech]

I would love to see the adoption of the NIST's new password guidelines as a starting point:

• User-generated passwords should be at least 8 characters in length.
• Users should be able to create passwords at least 64 characters in length.
• All ASCII/Unicode characters should be allowed, including emojis and spaces.
• Stored passwords should be hashed and salted, and never truncated. The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes.
• Passwords should not expire.
• Users should be prevented from using sequential characters (e.g., “1234”) or repeated characters (e.g., “aaaa”).
• Two-factor authentication (2FA) should not use SMS for codes.
• Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used.
• Users should be allowed 10 failed password attempts before being locked out of a system or service.
• Passwords should not have hints.
• Complexity requirements — like requiring special characters, numbers or uppercase letters — should not be used.
• Context-specific words, such as the name of the service or the individual’s username, should not be permitted.
• Prospective passwords should be compared against password breach databases and rejected if there’s a match.

The length thing is what will trip up most people. It should be at least 8 but that's it. Enforcing long password "just because" has shown to have the opposite effect. It makes people create gibberish password that aren't actually secure just to get to the limit. Also making them include different characters like A-Z, a-z, 0-9 isn't safe. It just leads to insecure passwords.

The only one I would see us not using is the last part about comparing them with online breech databases. For a self-hosted app that likely won't happen as those services tend to cost money.

[daVinci2793]

It adds some complexity, but a solid compromise between forcing healthy password policies and good security is customizable password policies. A password policy page under settings that allows the admins/root to change the policy would be ideal. That way, users that are hosting but not proxying/forwarding/sharing need not worry.

Additionally, if we copy nextcloud's homework and use their "password database" validator it could be a meaningful addition. The HIBP pwnedpasswords API they are using is free.

[daVinci2793]

https://haveibeenpwned.com/Passwords

It's actually pretty awesome, and if you dev tools the request, it's very simple.

[skyzuma]

any progressions?

[nichwall]

Could this be handled by using OIDC for SSO (or other authentication methods if added) instead of requiring ABS to enforce password policies? https://github.com/advplyr/audiobookshelf/issues/998

[Sapd]

@nichwall

Could this be handled by using OIDC for SSO (or other authentication methods if added) instead of requiring ABS to enforce password policies? #998

Yes every Identity Provider should be able to configure that properly, some even have very advanced features as mentioned above (like comparing with haveibeenpwned etc.). I think complexity wise it only makes sense that ABS has simple rules (like min. amount of characters), and for more advanced use cases people should configure OIDC and disable local auth.