[GH-ISSUE #521] Support password policy

kerem commented

2026-02-27 08:15:47 +03:00

Owner

Originally created by @S0obi on GitHub (Apr 3, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/521

Hello there,

It will be nice if lldap can actually support a global password policy. For now, lldap only checks that the password is 8 characters or more. It should be customizable by configuration with classic conditions :

Minimum number of characters
x lowercase characters
x uppercase characters
x numeric characters
x special characters

Originally created by @S0obi on GitHub (Apr 3, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/521 Hello there, It will be nice if lldap can actually support a global password policy. For now, lldap only [checks](https://github.com/lldap/lldap/blob/main/app/src/components/change_password.rs#L39) that the password is 8 characters or more. It should be customizable by configuration with classic conditions : - Minimum number of characters - x lowercase characters - x uppercase characters - x numeric characters - x special characters

kerem added the

enhancement

frontend

labels

2026-02-27 08:15:47 +03:00

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 3, 2023):

Sure, we can implement something like that (I'm open for PRs!)

Some things to keep in mind:

when changing passwords on the web interface, the server doesn't actually
see the password, so it's completely possible for a client to register a
weak password. The restrictions can be applied to the web UI, but that
won't stop a motivated user from registering a weak password.
when changing passwords through LDAP, what should we do if the password
doesn't match the criteria? Refuse it? If that's the case, then we need to
be able to surface the restrictions to the end user, otherwise that's a
very frustrating experience. We should probably accept whatever password is
sent (maybe over 8 characters anyway) and count on the frontend of the
service to enforce the policy.

On Mon, 3 Apr 2023, 22:41 Thibault Soubiran, @.***>
wrote:

Hello there,

It will be nice if lldap can actually support a global password policy.
For now, lldap only checks
https://github.com/lldap/lldap/blob/main/app/src/components/change_password.rs#L39
that the password is 8 characters or more. It should be customizable by
configuration with classic conditions :

Minimum number of characters

x lowercase characters

x uppercase characters

x numeric characters

x special characters

—
Reply to this email directly, view it on GitHub
https://github.com/lldap/lldap/issues/521, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWP4ONZJ7ZFIYURA2PDW7MYYNANCNFSM6AAAAAAWR2A7VY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@nitnelave commented on GitHub (Apr 3, 2023): Sure, we can implement something like that (I'm open for PRs!) Some things to keep in mind: - when changing passwords on the web interface, the server doesn't actually see the password, so it's completely possible for a client to register a weak password. The restrictions can be applied to the web UI, but that won't stop a motivated user from registering a weak password. - when changing passwords through LDAP, what should we do if the password doesn't match the criteria? Refuse it? If that's the case, then we need to be able to surface the restrictions to the end user, otherwise that's a very frustrating experience. We should probably accept whatever password is sent (maybe over 8 characters anyway) and count on the frontend of the service to enforce the policy. On Mon, 3 Apr 2023, 22:41 Thibault Soubiran, ***@***.***> wrote: > Hello there, > > It will be nice if lldap can actually support a global password policy. > For now, lldap only checks > <https://github.com/lldap/lldap/blob/main/app/src/components/change_password.rs#L39> > that the password is 8 characters or more. It should be customizable by > configuration with classic conditions : > > - Minimum number of characters > - x lowercase characters > - x uppercase characters > - x numeric characters > - x special characters > > — > Reply to this email directly, view it on GitHub > <https://github.com/lldap/lldap/issues/521>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWP4ONZJ7ZFIYURA2PDW7MYYNANCNFSM6AAAAAAWR2A7VY> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 3, 2023):

Also, another thing to consider is that the recommendations in terms of security are usually focused on password length alone rather than special characters. If anything, measuring the entropy is best.
Something that I've had as a wip for a while is support for haveibeenpwned to check if the password is in any leak (requires a paying API key though).

One other thing we could consider is if the password is weak, to add a plug for a password manager (or an article explaining the benefits of a password manager).

@nitnelave commented on GitHub (Apr 3, 2023): Also, another thing to consider is that the recommendations in terms of security are usually focused on password length alone rather than special characters. If anything, measuring the entropy is best. Something that I've had as a wip for a while is support for haveibeenpwned to check if the password is in any leak (requires a paying API key though). One other thing we could consider is if the password is weak, to add a plug for a password manager (or an article explaining the benefits of a password manager).

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@pixelrazor commented on GitHub (Apr 4, 2023):

Some random thoughts on this:

We can , probably even today afaik, have one of those password strength bars for indicators. We coul;d probably pass it (some sort of policy) to the front end for live feedback, but with or without that piece, we could just implement it in the graphql api?

@pixelrazor commented on GitHub (Apr 4, 2023): Some random thoughts on this: We can , probably even today afaik, have one of those password strength bars for indicators. We coul;d probably pass it (some sort of policy) to the front end for live feedback, but with or without that piece, we could just implement it in the graphql api?

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 4, 2023):

Sending the password to the backend for strength check would defeat the entire purpose of OPAQUE :D
The idea is that you're not trusting the connection/server/storage to protect your password, so you never send it to the server (yes, I know, LDAP sends it in clear). So all the checking has to be on the client side, making it optional (you can just run the lldap_set_user_password binary and give it an arbitrarily weak password, the server can't check that).

The password strength bar is basically what I meant by measuring the entropy; it's still approximate, but it's better. The idea is that if a user comes up with a 30 character passphrase that doesn't have a number or a special character, that's still fine.

But really, we should push users to use password managers (I'm partial to Bitwarden since it can be self-hosted, but 1Password is also good, or KeyPass + some syncing service).

@nitnelave commented on GitHub (Apr 4, 2023): Sending the password to the backend for strength check would defeat the entire purpose of OPAQUE :D The idea is that you're not trusting the connection/server/storage to protect your password, so you never send it to the server (yes, I know, LDAP sends it in clear). So all the checking has to be on the client side, making it optional (you can just run the `lldap_set_user_password` binary and give it an arbitrarily weak password, the server can't check that). The password strength bar is basically what I meant by measuring the entropy; it's still approximate, but it's better. The idea is that if a user comes up with a 30 character passphrase that doesn't have a number or a special character, that's still fine. But really, we should push users to use password managers (I'm partial to Bitwarden since it can be self-hosted, but 1Password is also good, or KeyPass + some syncing service).

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@pixelrazor commented on GitHub (Apr 4, 2023):

ignore me, it's too early to remember everything :)

@pixelrazor commented on GitHub (Apr 4, 2023): ignore me, it's too early to remember everything :)

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@leanderjanssen commented on GitHub (Apr 6, 2023):

What about zxcvbn?
It's a password strength estimator developed by dropbox.
There is a rust library available at: https://github.com/shssoichiro/zxcvbn-rs

Authelia is also using this.

@leanderjanssen commented on GitHub (Apr 6, 2023): What about [`zxcvbn`](https://github.com/dropbox/zxcvbn)? It's a password strength estimator developed by dropbox. There is a rust library available at: https://github.com/shssoichiro/zxcvbn-rs Authelia is also using this.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 6, 2023):

@leanderjanssen nice! I think that's a good candidate for the "measuring entropy"-equivalent category. I think also checking if the password was leaked would help on top.

@nitnelave commented on GitHub (Apr 6, 2023): @leanderjanssen nice! I think that's a good candidate for the "measuring entropy"-equivalent category. I think also checking if the password was leaked would help on top.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@binaryben commented on GitHub (Apr 8, 2023):

I'd actually make an argument against this suggestion. LDAP is LDAP. Let this tool just focus on providing LDAP and mark this as out of scope for the reasons mentioned here. LDAP should be used with other tools like Authelia (imho) which can do the security checks and password strength enforcement. Personally I'm going as far as disabling the password reset functionality from LLDAP in my config and leaving it to other tools. I think it's good LLDAP offers the option for password reset, but that's as far as it should go - if you can't tell, I like the UNIX philosophy of tools doing one thing and doing it well. This will add a lot of complexity.

EDIT: Never mind, I think many of the issues will be addressed anyway in supporting HIBP which is already being added.

@binaryben commented on GitHub (Apr 8, 2023): I'd actually make an argument against this suggestion. LDAP is LDAP. Let this tool just focus on providing LDAP and mark this as out of scope for [the reasons mentioned here](https://github.com/lldap/lldap/issues/521#issuecomment-1495005451). LDAP should be used with other tools like Authelia (imho) which can do the security checks and password strength enforcement. Personally I'm going as far as disabling the password reset functionality from LLDAP in my config and leaving it to other tools. I think it's good LLDAP offers the option for password reset, but that's as far as it should go - if you can't tell, I like the UNIX philosophy of tools doing one thing and doing it well. This will add a lot of complexity. EDIT: Never mind, I think many of the issues will be addressed anyway in supporting HIBP which is already being added.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@S0obi commented on GitHub (Apr 9, 2023):

My main point about creating this issue is that LLDAP will actually become a minimum viable option for users that have simple needs and are looking for an easy drop-in replacement for OpenLDAP. I understand the point behind using Authelia or Keycloak for such "advanced" mechanisms, however I will consider "strong password" requirement as something that should belong the the core project.

I proposed the traditional password policy pattern because I felt that most company users may have this need. However I agree that we may want to be more "up-to-date" for this project and implement part of NIST Special Publication 800-63B. Some important points from this publication :

Check passwords against breached password lists or dictionaries
Do not request regular password change
Password length at least 8 characters (Length > Complexity)

Just my 2 cents, but I didn't find too much mentions for "password strength indicator" in the literature. Password strength indicators that just do "simple mathematical computation" are discouraged by this Troy Hunt blog post.

@leanderjanssen 👍 I will also recommend zxcvbn-rs that is the Rust port for zxcvbn (from dropbox) that is really more that just simple entropy calculation.

HIBP lookup may be useful as well, but my humble opinion should be that it must be optional and disabled by default. Should be another separated PR as it may lead to some discussions.

@S0obi commented on GitHub (Apr 9, 2023): My main point about creating this issue is that LLDAP will actually become a minimum viable option for users that have simple needs and are looking for an easy drop-in replacement for OpenLDAP. I understand the point behind using Authelia or Keycloak for such "advanced" mechanisms, however I will consider "strong password" requirement as something that should belong the the core project. I proposed the traditional password policy pattern because I felt that most company users may have this need. However I agree that we may want to be more "up-to-date" for this project and implement part of [NIST Special Publication 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html). Some important points from this publication : - Check passwords against breached password lists or dictionaries - Do not request regular password change - Password length at least 8 characters (Length > Complexity) Just my 2 cents, but I didn't find too much mentions for "password strength indicator" in the literature. Password strength indicators that just do "simple mathematical computation" are discouraged by this [Troy Hunt blog post](https://www.troyhunt.com/password-strength-indicators-help-people-make-dumb-choices/). @leanderjanssen 👍 I will also recommend [zxcvbn-rs](https://github.com/shssoichiro/zxcvbn-rs) that is the Rust port for [zxcvbn (from dropbox)](https://github.com/dropbox/zxcvbn) that is really more that just simple entropy calculation. HIBP lookup may be useful as well, but my humble opinion should be that it must be optional and disabled by default. Should be another separated PR as it may lead to some discussions.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@binaryben commented on GitHub (Apr 10, 2023):

will actually become a minimum viable option for users that have simple needs and are looking for an easy drop-in replacement for OpenLDAP

Given I've just replaced OpenLDAP and LAM with this, I am inclined to agree now and have changed my prior thoughts. If it's possible to do so without adding much complexity or breaking integrations with services that build on the core of LDAP itself (not LLDAP; i.e. what happens if there is a conflict between password policies in both systems?), then it sounds good to me. One small thing to note though:

[it should] .. check passwords against breached password lists or dictionaries

and ...

HIBP lookup may be useful as well, but my humble opinion should be that it must be optional and disabled by default.

... contradict each other. HIBP exact purpose is to check if passwords have been breached. I hope you're not suggesting LLDAP comes with a dictionary of known passwords that then needs to be kept up to date by the maintainers of the project and administrators of installations?

Sending the password to the backend for strength check would defeat the entire purpose of OPAQUE

This is going to be the most important factor. HIBP is the answer to checking if a password has been used as it only uses a hash of the password.

But really, we should push users to use password managers (I'm partial to Bitwarden since it can be self-hosted, but 1Password is also good, or KeyPass + some syncing service).

Also a happy user of Bit/Vaultwarden (I pay and self-host). Highly recommend this approach. I won't know my own password to my domain and I'll encourage any other members to do the same. I only know my password to my password manager, primary email (since every service seems to insist on letting you change a password as easy as clicking a link from an email... 🤦🏼‍♂️) and my 2FA system.

@binaryben commented on GitHub (Apr 10, 2023): > will actually become a minimum viable option for users that have simple needs and are looking for an easy drop-in replacement for OpenLDAP Given I've just replaced OpenLDAP and LAM with this, I am inclined to agree now and have changed my prior thoughts. If it's possible to do so without adding much complexity or breaking integrations with services that build on the core of LDAP itself (not LLDAP; i.e. what happens if there is a conflict between password policies in both systems?), then it sounds good to me. One small thing to note though: > [it should] .. check passwords against breached password lists or dictionaries and ... > HIBP lookup may be useful as well, but my humble opinion should be that it must be optional and disabled by default. ... contradict each other. HIBP exact purpose is to check if passwords have been breached. I hope you're not suggesting LLDAP comes with a dictionary of known passwords that then needs to be kept up to date by the maintainers of the project and administrators of installations? > Sending the password to the backend for strength check would defeat the entire purpose of OPAQUE This is going to be the most important factor. HIBP is the answer to checking if a password has been used as it only uses a hash of the password. > But really, we should push users to use password managers (I'm partial to Bitwarden since it can be self-hosted, but 1Password is also good, or KeyPass + some syncing service). Also a happy user of Bit/Vaultwarden (I pay and self-host). Highly recommend this approach. I won't know my own password to my domain and I'll encourage any other members to do the same. I only know my password to my password manager, primary email (since every service seems to insist on letting you change a password as easy as clicking a link from an email... 🤦🏼‍♂️) and my 2FA system.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@S0obi commented on GitHub (Apr 10, 2023):

[it should] .. check passwords against breached password lists or dictionaries

and ...

HIBP lookup may be useful as well, but my humble opinion should be that it must be optional and disabled by default.

... contradict each other. HIBP exact purpose is to check if passwords have been breached. I hope you're not suggesting LLDAP comes with a dictionary of known passwords that then needs to be kept up to date by the maintainers of the project and administrators of installations?

On the contradiction you are pointing out, I really think that the HIBP lookup is a good idea, but I suppose that some people will be reluctant about communicating information about users password to an external server, even if HIBP is really strong about privacy. I just recommended to make it optional, so this will not be a no-go for some LLDAP users.

If LLDAP community wants to go the dictionnary way, I think that LLDAP instance administrators should be responsible peaking and maintaining dictionaries (depending on their own needs and contexts). The maximum I will expect from the project will be to actually recommend some data sources like SecLists.

@S0obi commented on GitHub (Apr 10, 2023): > > [it should] .. check passwords against breached password lists or dictionaries > > and ... > > > HIBP lookup may be useful as well, but my humble opinion should be that it must be optional and disabled by default. > > ... contradict each other. HIBP exact purpose is to check if passwords have been breached. I hope you're not suggesting LLDAP comes with a dictionary of known passwords that then needs to be kept up to date by the maintainers of the project and administrators of installations? On the contradiction you are pointing out, I really think that the HIBP lookup is a good idea, but I suppose that some people will be reluctant about communicating information about users password to an external server, even if HIBP is [really strong about privacy](https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity). I just recommended to make it optional, so this will not be a no-go for some LLDAP users. If LLDAP community wants to go the dictionnary way, I think that LLDAP instance administrators should be responsible peaking and maintaining dictionaries (depending on their own needs and contexts). The maximum I will expect from the project will be to actually recommend some data sources like [SecLists](https://github.com/danielmiessler/SecLists).

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 10, 2023):

A couple of comments:

I don't want to manage password dictionaries or add GB of downloads when someone installs LLDAP.
HIBP will always be optional, due to the requirement for a paying API key.

@nitnelave commented on GitHub (Apr 10, 2023): A couple of comments: - I don't want to manage password dictionaries or add GB of downloads when someone installs LLDAP. - HIBP will _always_ be optional, due to the requirement for a paying API key.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@h-2 commented on GitHub (Jan 19, 2026):

Thanks for working on this! It seems there have been some changes, but actual password requirements cannot be set, yet, correct?

FWIW: I don't need any specific policies ("at least one upper case letter"), I'd be fine with just a numeric minimumPwdComplexity value in the config that prevents my users from using setting their password to secret1234. I am also fine with this being client-side in the web-ui.

@h-2 commented on GitHub (Jan 19, 2026): Thanks for working on this! It seems there have been some changes, but actual password requirements cannot be set, yet, correct? FWIW: I don't need any specific policies ("at least one upper case letter"), I'd be fine with just a numeric `minimumPwdComplexity` value in the config that prevents my users from using setting their password to `secret1234`. I am also fine with this being client-side in the web-ui.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 20, 2026):

The attached PR (#1282 ) has been reviewed and needs some work before it can get merged. If @gplubeck wants to finish it, it'll get merged, otherwise you can pick up the work if you want to push it through (I'll give credit to both).

@nitnelave commented on GitHub (Jan 20, 2026): The attached PR (#1282 ) has been reviewed and needs some work before it can get merged. If @gplubeck wants to finish it, it'll get merged, otherwise you can pick up the work if you want to push it through (I'll give credit to both).

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@gplubeck commented on GitHub (Jan 21, 2026):

@h-2 I cannot do anything before this weekend, but at that point I can make the fixes and push.

If you need it sooner than that @nitnelave has made some indepth fix requests and should be relatively simple.

@gplubeck commented on GitHub (Jan 21, 2026): @h-2 I cannot do anything before this weekend, but at that point I can make the fixes and push. If you need it sooner than that @nitnelave has made some indepth fix requests and should be relatively simple.

kerem commented

2026-02-27 08:15:48 +03:00

Author

Owner

@h-2 commented on GitHub (Jan 21, 2026):

I don't need it sooner, and thank you very much! I hope to find some time over the next months to learn Rust and hope to be of more help then.

@h-2 commented on GitHub (Jan 21, 2026): I don't need it sooner, and thank you very much! I hope to find some time over the next months to learn Rust and hope to be of more help then.

Rows
Columns

[GH-ISSUE #521] Support password policy #191