Support password policy

[S0obi]

Support password policy

[nitnelave]

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.

[leanderjanssen]

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.

[binaryben]

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.

[nitnelave]

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 <#521>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGCPWP4ONZJ7ZFIYURA2PDW7MYYNANCNFSM6AAAAAAWR2A7VY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nitnelave]

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

[pixelrazor]

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?

[nitnelave]

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

[pixelrazor]

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

[nitnelave]

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

[S0obi]

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.

[binaryben]

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.

[S0obi]

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