[bitnami/openldap] Add support for setting the password crypt format

[mistial-dev]

Description of the change

This patch adds the configuration option "LDAP_PASSWORD_CRYPT_SALT_FORMAT", allowing the crypt salt format to be set in the container environment variables.

Additionally, this patch changes the default for password encoding from SHA (which is now retired by NIST) to salted SHA-256 using crypt() (which defaults to 5,000 rounds). This change is also applied to administrative passwords (admin, config admin, accesslog admin).

Benefits

NIST recommends moving away from SHA-1 due to insecurity.

The SHA-1 algorithm, one of the first widely used methods of protecting electronic information, has reached the end of its useful life, according to security experts at the National Institute of Standards and Technology (NIST). The agency is now recommending that IT professionals replace SHA-1, in the limited situations where it is still used, with newer algorithms that are more secure.

While it is possible to use a third party module for SHA-256 and SHA-512 from an atlassian employee, it is simpler and more compatible to use {CRYPT} support. This allows the number of rounds to be user-configured for increased attack resistance, allows the algorithm to be specified, and provides the hash in a way that other applications using compatible crypt() implementations can interoperate with.

This improves the default security posture while supporting existing configurations.

Possible drawbacks

Applications designed to work directly with hash values (for example, the SHA or MD5 hash) will not work unless they also have support for crypt passwords. The previous behaviour can be restored by setting LDAP_PASSWORD_HASH to "SSHA".

Note that applications that bind as a user with a simple password should be unaffected by this change. Only applications using the password hash directly may be affected.

Additional information

To take advantage of the new security defaults, LDAP_CONFIGURE_PPOLICY and LDAP_PPOLICY_HASH_CLEARTEXT should be set to yes. This will result in user passwords automatically being hashed, even if they are set in plaintext. This applies to users created through the LDAP_USERS and LDAP_PASSWORDS environment variables.

[mistial-dev]

I kept the automatic plaintext conversion disabled in the interest of compatibility. I could change that as well to make this more secure out of the box, or add a LDAP_HARDENED environment variable that sets some sensible security defaults, including adding ACLs.

Unless you need something like MSCHAPv2 support (VPN for windows, mainly), it's a very good idea to have ACLs set which prohibit reading the contents of the userPassword attribute. If I were doing a hardened config, I'd also be tempted to limit anonymous binding and disable enumeration by users (permitting search by email or username), and adding an ou for service accounts that had full access.

[andresbono]

Hi, thank you very much for this PR, it looks like a very nice addition! I will run some manual tests on my side and I'll get back to you.

Thanks again!

[andresbono]

Could you please check my comments? Thanks!

[andresbono]

If LDAP_PASSWORD_CRYPT_SALT_FORMAT is configurable, should it be used here instead of hardcoding the value?

[mistial-dev]

This approach forced the use of the higher security default for the admin password. I could make it configurable, but it wouldn't force the higher security option for the admin password.

[andresbono]

I see. I think it should be configurable. If users may need different formats for admin and the rest, maybe we can define a new env-var: LDAP_ADMIN_PASSWORD_CRYPT_SALT_FORMAT. What do you think?

[mistial-dev]

That makes sense.

[mistial-dev]

I see. I think it should be configurable. If users may need different formats for admin and the rest, maybe we can define a new env-var: LDAP_ADMIN_PASSWORD_CRYPT_SALT_FORMAT. What do you think?

Added. Additionally, I changed the defaults to enable ppolicy and hash plaintext passwords by default.

It can be turned off easily enough, either through environment variables or ldapmodify after the fact. Sane defaults are better, and with Microsoft Active Directory using hashed passwords, there's precedent for not doing plaintext passwords. It also works fine for shadow support, and the use of CRYPT instead of something weird increases compatibility when used elsewhere.

[mistial-dev]

bitnami/openldap/2.5/debian-12/rootfs/opt/bitnami/scripts/libopenldap.sh

Looking at them now.

[andresbono]

Thank you, could you please check my comment?

[andresbono]

I see. I think it should be configurable. If users may need different formats for admin and the rest, maybe we can define a new env-var: LDAP_ADMIN_PASSWORD_CRYPT_SALT_FORMAT. What do you think?

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[mistial-dev]

Applying this through the policy means that it's applied when necessary. It doesn't force a particular hashed format if non-plaintext passwords are applied.

[mistial-dev]

Setting this as the default ensures that password hashing is used even when the environment variables are used to pass credentials and no policy is set. Leaving plaintext passwords around is risky.

[andresbono]

@mistial-dev, just one minor thing, The DCO check failed. Please read https://github.com/bitnami/containers/pull/70398/checks?check_run_id=30415074724 to see how you can fix that. Thanks!

[gongomgra]

Hi @mistial-dev,

Thanks for fixing the DCO issue. Can you rebase the main branch on your fork and fix the conflicts?

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Pull Request. Do not hesitate to reopen it later if necessary.