starred/audiobookshelf

Fork 0

mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-03-02 22:46:56 -05:00

[Enhancement]: Password Policy #997

New issue

Open

opened 2026-02-20 01:13:23 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-20 01:13:23 -05:00

Owner

Originally created by @theniwo on GitHub (Feb 25, 2023).

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

Originally created by @theniwo on GitHub (Feb 25, 2023). ### 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

deekerman added the

enhancement

label

2026-02-20 01:13:23 -05:00

deekerman commented

2026-02-20 01:13:23 -05:00

Author

Owner

@DieselTech commented on GitHub (Feb 25, 2023):

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.

@DieselTech commented on GitHub (Feb 25, 2023): 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.

deekerman commented

2026-02-20 01:13:23 -05:00

Author

Owner

@daVinci2793 commented on GitHub (Jun 12, 2023):

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 commented on GitHub (Jun 12, 2023): 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. ![image](https://github.com/advplyr/audiobookshelf/assets/49510984/6a87212e-7cd4-4963-b646-d3f499ea31a7)

deekerman commented

2026-02-20 01:13:24 -05:00

Author

Owner

@daVinci2793 commented on GitHub (Jun 12, 2023):

https://haveibeenpwned.com/Passwords

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

@daVinci2793 commented on GitHub (Jun 12, 2023): https://haveibeenpwned.com/Passwords It's actually pretty awesome, and if you dev tools the request, it's very simple.

deekerman commented

2026-02-20 01:13:24 -05:00

Author

Owner

@skyzuma commented on GitHub (Jun 30, 2023):

any progressions?

@skyzuma commented on GitHub (Jun 30, 2023): any progressions?

deekerman commented

2026-02-20 01:13:24 -05:00

Author

Owner

@nichwall commented on GitHub (Dec 9, 2023):

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

@nichwall commented on GitHub (Dec 9, 2023): 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

deekerman commented

2026-02-20 01:13:25 -05:00

Author

Owner

@Sapd commented on GitHub (Jan 25, 2024):

@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.

@Sapd commented on GitHub (Jan 25, 2024): @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.

deekerman commented

2026-02-20 01:13:25 -05:00

Author

Owner

@kulps commented on GitHub (Aug 17, 2025):

I hope there's a way to enable MFA at the very least, though adopting NIST's guidelines as DieselTech suggested is also great.

@kulps commented on GitHub (Aug 17, 2025): I hope there's a way to enable MFA at the very least, though adopting NIST's guidelines as DieselTech suggested is also great.

deekerman commented

2026-02-20 01:13:25 -05:00

Author

Owner

@Vito0912 commented on GitHub (Aug 18, 2025):

MFA/2FA currently is not planned to be added. See https://github.com/advplyr/audiobookshelf/issues/4480

You can do this via OIDC though

@Vito0912 commented on GitHub (Aug 18, 2025): MFA/2FA currently is not planned to be added. See https://github.com/advplyr/audiobookshelf/issues/4480 You can do this via OIDC though

deekerman commented

2026-02-20 01:13:25 -05:00

Author

Owner

@kulps commented on GitHub (Aug 18, 2025):

Thanks for confirming. It's too bad, but I appreciate knowing.

@kulps commented on GitHub (Aug 18, 2025): Thanks for confirming. It's too bad, but I appreciate knowing.