[FEATURE REQUEST] Password Expiration Policy

[mbay-ODW]

Motivation
Currently there is no implementation of setting the non editable password expired attribute. However in using lldap it might be useful to define a certain password expiration policy such that passwords need to be rotated. This makes it challenging to enforce password rotation policies for users. This feature is essential for enhancing security and ensuring that users regularly update their passwords.

Describe the solution you'd like
OpenLdap uses the attribute: pwdMaxAge and pwdChangedTime that indicates when a password was last changed and need to be changed again based on the configured policy.

1. Populate the attributes that stores the expiration date of the user's password. This attribute should be set when the user changes their password or when it's initially set by the administrator.
2. Provide a mechanism to configure password expiration policies.
3. (Optional) Implement a mechanism to notify users when their password is about to expire.

Describe alternatives you've considered
Currently, administrators may have to rely on external scripts or tools to manage password expiration policies that would basically change the password thus that users have to reset them.

Additional context
Implementing password expiration in LDAP using the "lldap" library would greatly enhance security and ease the management of user accounts by providing a native and integrated solution. It would benefit organizations that rely on LDAP for authentication and user management, ensuring that password policies are enforced consistently and efficiently. I´m using it together with Authelia which reads the attributes of

[Firstyear]

Password expiration is a security anti-pattern. It has been known for more than a decade to reduce password quality and cause more security issues than it resolves.

My advice to @nitnelave would be to never implement this "antifeature".

[mbay-ODW]

As much as I agree with @Firstyear, some data privacy officers heavily jump on that topic.

[nomandera]

Whilst I strongly agree with @Firstyear I should point out artificial password expiration unfortunately remains a common requirements of almost all accreditation and cyber security insurance polices.

[nitnelave]

The main target of the LLDAP project is self-hosted servers, by individuals or small organizations who don't need accreditation or privacy officers. Regarding privacy/security, though I can vouch for the design of LLDAP, it hasn't been audited for use in a sensitive environment, so I'm not sure it'd be the darling of all privacy officers :)

It sounds like you want to use it professionally, in a company setting: although I provide my work for free, it's something else to work to make money for someone else ;) As I'm sure you understand, I won't be prioritizing this feature since it doesn't benefit the main userbase. However, I'm open to contributions and will happily review them and merge them as long as they don't hurt the user experience for the average user, contribute negatively to code quality or incur a heavy maintenance burden.

Now, about the specific feature, I think we all agree with @Firstyear. I like to link to the NIST password guidelines: https://blog.netwrix.com/2022/11/14/nist-password-guidelines/
In fact, in that spirit I have a WIP branch for integration with HIBP that more or less just needs a better front-end, and I would heartily welcome contributions there! We can also add (client-only) password checks (like checking for repeated characters, the user's name/email or the domain/"LLDAP"). I say client-only since the server never receives the actual password and is thus incapable of checking it. Same goes for HIPB, it would be client-only.

If you're dead set on this feature, you can try implementing it yourself! I can provide hints/starting points if you're having trouble. Don't hesitate to join the #development channel on Discord where we can chat about this.

One more thing: if you rely on LLDAP professionally, please consider supporting the project!

[Firstyear]

Now, about the specific feature, I think we all agree with @Firstyear. I like to link to the NIST password guidelines: https://blog.netwrix.com/2022/11/14/nist-password-guidelines/

The complete version is https://pages.nist.gov/800-63-3/sp800-63b.html specifically section 5.1.1.2:

"""
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
"""

I'm going to go further and say that if you have a security auditor or company that "requires" this, you should clearly explain to your management why that auditor or company is incompetent and you should not pay them for any services. As an industry, we should not continue to pander to auditors who are preaching outdated, incorrect, and dangerous information.

[mbay-ODW]

@nitnelave

Thanks for your really long and detailed answer.
I´m currently using your project (besides using private on my Homelab) for an internal project within the German Red Cross organisation. So unfortunately Germany is very strict about data governance and even in such projects data privacy officers need to give their ok.
So besides the fact that I´m doing this non-commercially and only on a voluntary basis, I also have to deal with those types of discussions.....

I´m not much of a rust guy. However that should´t be an excuse. Never stop learning. Maybe this could be an entry point.
I will ping you on discord about that.

@Firstyear

I appreciate your links, I will use them for a discussion. However you also might know how those types of discussions end up....
I also found another link from the German BSI (Bundesinsititut für Sicherheit) that also indicates that password rotation should not be applied BSI-LINK. This might help somebody that has the same "struggle" :-(

@ALL:

While checking you links I also saw that password expiration on suspected breach is highly recommended, such that this feature request still makes some sense. Maybe I need to refine the requirements. From an administration point of view I need to be able to declare a password on a user as expired. From what I saw in the Authelia implementation this is handled via ldap Codes Authelia- Link:

data 533 : account disabled
date 532 : account pwd expired
data 773 : account pwd reseted and need to be changes
data 775 : account_locked

[Firstyear]

I appreciate your links, I will use them for a discussion. However you also might know how those types of discussions end up....

I am available to be involved in any of these discussions - email or calls. I'm sure you can find my qualifications elsewhere :)

I also found another link from the German BSI (Bundesinsititut für Sicherheit) that also indicates that password rotation should not be applied BSI-LINK. This might help somebody that has the same "struggle" :-(

Good to know the BSI recommends the same!

While checking you links I also saw that password expiration on suspected breach is highly recommended, such that this feature request still makes some sense. Maybe I need to refine the requirements. From an administration point of view I need to be able to declare a password on a user as expired. From what I saw in the Authelia implementation this is handled via ldap Codes Authelia- Link:

You actually don't want to "expire" the password here in the sense that "on next login the user must change it". If you suspect the account has been compromised you need to remove the compromised credential and issue an out-of-band password reset. That way an attacker who has the password is not in a position to then change the password by simply logging in (giving the appearance that it was the user who did the reset, when it was actually the attacker who now remains in control of the account).

[nitnelave]

I think in that scenario the user would log in and immediately be sent a password reset email and get logged out. So an attacker could at most trigger a password reset email.

But since this also covers LDAP logins, it's a bit more complicated: not every application displays the error messages from LDAP, so they would just see that the login fails. Hopefully they also see the password reset email, but that's far from a given.

A better solution would be to proactively send them an email telling them that they need to reset their password when you invalidate the password. Still it's not ideal since they might miss the email, but I don't see a way to guarantee that they see a proper message on login.

For that feature, you don't actually really need to modify LLDAP (although it might be more convenient): you can write a script that goes over every user, (get the email through the API), send them an email, and set their password to a randomly generated one.

[Firstyear]

But since this also covers LDAP logins, it's a bit more complicated: not every application displays the error messages from LDAP, so they would just see that the login fails. Hopefully they also see the password reset email, but that's far from a given.

100% this - most LDAP applications only do "bind and search". They don't understand any of the extra extensions or features that LDAP supports.

A better solution would be to proactively send them an email telling them that they need to reset their password when you invalidate the password. Still it's not ideal since they might miss the email, but I don't see a way to guarantee that they see a proper message on login.

But it also stops an attackers access, and if the user missed the email they can request support via other channels. So I think this is the correct approach.

For that feature, you don't actually really need to modify LLDAP (although it might be more convenient): you can write a script that goes over every user, (get the email through the API), send them an email, and set their password to a randomly generated one.

[nitnelave]

Thinking more about it, this could be a good candidate for a plugin, see #714

[n-connect]

@nitnelave @Firstyear @mbay-ODW

I'm a happy user of lldap, also working on some additions/PR, but learning Rust in the meantime. I've seen and understand the original goal of lldap: target audience is the homeuser/labs/etc. I think is just become too good, and really easy to use -> so people started to use it at anywhere/everywhere :)

My 2 cents from the ITSec field. People usually turns to "provider's best practice", or proven, industry accepted security guides, like OWASP and its siblings, PCI-DSS, CIS, etc. My goal here, to show some background info and so to show that "the idea of replacing password by expiration is bad, and it is recognized already" is not correct in this form. So do not want to start a debate, flame, nothing like that. Just sharing the details I think its worth here and try to be short at the same time.

All that It is important, because lldap as an LDAP server is a security product on its own.

Password expiration is not a bad thing, also not a silver bullet, should be used in its place. I've met many people who never used LDAP based "big" environments, don't understand why they need to change their [MS AD] pw and they referred their practice not changing their pw on their [G]mail account. Well, from not the same reasons, but both needs to be changed periodically. This is a way you can lower the risks of getting hacked through your, or your user's password. Again, there is a trend talking about password will go away, so why bother but that's another topic altogether. Risk levels varies on the LDAP directroy service you run, and the mixture of them, Also changing password is in hand-in-hand with the "not use the same password for different accounts/systems", especially not mixing free internet based ones with local accounts. So an MS AD without reasonable good password expiration policy is a direct recipe for quicker & easier breach. Just remembering first 2-3 from the several EH projects where checking for very old password (10+ years) was the first step of business and gave access in record time. So I can tell it is still the de facto first steps for many hacking attempts, fine-tuned/depending on the target.

The mentioned NIST guideline about digital identity need to be read and applied altogether. Cherry-picking one paragraph from one sub point from it can be misleading. Please apply them in a holistic approach as it supposed (a.k.a weakest link in a chain). Also It does not say or state there should not be password expiration capability, or it is wrong to expiry a password. It tells not to use it mindlessly just for sake of using it - that has proven counterproductive. Nevertheless there are architectures where you have to do it anyway - in a planned manner/design with all the other of actual recommendations. If you check all the other IT Audit or ITSec certification frameworks(ISO27k1, COBIT/ISACA, PCI-DSS, etc.), majority still not loosened in this subject, or in the complete opposite side - mostly born from bad MS AD experiences, but since that the hacking steps used on everywhere.

About the auto pw reset e-mail:

• fighting against an attack scenario by design means, there should not be an auto pw reset e-mail option. Because an attacker most likely owns/access the pw reset e-mail account too. Instead a rate-limiting, and/or disabling accounts that "most likely" compromised
• pw expiration should be handled by giving the ability at login to provide the old pw and new one twice.
• If its too old, or expired a long time ago: instead of the above, be able to set to disable the user account on not using them (hello service users!) and notify the (lldap) admin of user's inactivity ->disabling, plus login attempts afterwards.
  Quite the same what @mbay-ODW wrote.in Jan. 4.

Closing out ITSec capabilities, as this password expiration policy, or disabling users #750 #904, or HTTPS #813 will render lldap less resilient from ITSec point of view. Unfortunately it is not dependent on if you are a home-lab user or not, everybody, individuals get attacked, at least since the crypto-wallets.

On the other hand, I also understand @nitnelave 's stance just not jumping on these features to implement them on the spot. :) Lldap is good, will need more help.

Sorry for the long post.

@nitnelave please contact me if I can help in decisions in this area, unfortunately on Rust coding I'm no good :)

[nitnelave]

I think this is the kind of question for which there is no one-size-fits-all solution, and especially small self-hosted servers don't need password policies.

The way I picture it, it can be a plugin (or a series of plugins) once we have the API for it. Then you can write whatever rules you want in Lua.

[n-connect]

Plugin API sounds good.

Broadening the horizons on the whole homelab/selfhosted base: homelab subreddit Smart Home and Homelab network diagram after 4 years of evolution :

• home lab - check
• selfhosted - check

This is the link I pick-up, when I talk about system complexity with a customer. :D

[nitnelave]

I'd still wager that they have fewer users than services and they know all of them by first name :D
Part of the expectation of a homelab service is that you trust users not to actively try to hack the system or do stupid stuff, and if stuff breaks they can come to you to fix it.