Hello,
using slapo-ppolicy I could configure slapd to hash a password if it's sent unhashed.
moduleload ppolicy.la moduleload argon2.la password-hash {ARGON2}
database mdb suffix dc=test ... overlay ppolicy ppolicy_default "cn=default,ou=ppolicies,dc=test" ppolicy_hash_cleartext
That work and I could hash them using ARGON2.
But clients could still hash a password them self and write '{MD5}...' as userPassword for example. Is it possible to reject any userPasswords prefixed with hash schema?
Andreas
Look up olcPPolicyHashCleartext On Nov 26, 2021, 5:35 PM -0500, A. Schulze sca@andreasschulze.de, wrote:
Hello,
using slapo-ppolicy I could configure slapd to hash a password if it's sent unhashed.
moduleload ppolicy.la moduleload argon2.la password-hash {ARGON2}
database mdb suffix dc=test ... overlay ppolicy ppolicy_default "cn=default,ou=ppolicies,dc=test" ppolicy_hash_cleartext
That work and I could hash them using ARGON2.
But clients could still hash a password them self and write '{MD5}...' as userPassword for example. Is it possible to reject any userPasswords prefixed with hash schema?
Andreas
On 11/26/21 23:34, A. Schulze wrote:
using slapo-ppolicy I could configure slapd to hash a password if it's sent unhashed. > [..] overlay ppolicy ppolicy_default "cn=default,ou=ppolicies,dc=test" ppolicy_hash_cleartext [..] That work and I could hash them using ARGON2. [..] Is it possible to reject any userPasswords prefixed with hash schema?
See slapo-ppolicy(5) for attribute 'pwdCheckQuality'.
Ciao, Michael.
Am 27.11.21 um 00:50 schrieb Michael Ströder:
On 11/26/21 23:34, A. Schulze wrote:
using slapo-ppolicy I could configure slapd to hash a password if it's sent unhashed. > [..] overlay ppolicy ppolicy_default "cn=default,ou=ppolicies,dc=test" ppolicy_hash_cleartext [..] That work and I could hash them using ARGON2. [..] Is it possible to reject any userPasswords prefixed with hash schema?
See slapo-ppolicy(5) for attribute 'pwdCheckQuality'.
I set pwdCheckQuality=2 and the system behave in the desired manner. Thanks for the hint!
Andreas
"A. Schulze" sca@andreasschulze.de schrieb am 26.11.2021 um 23:34 in
Nachricht a8e1310c-2367-34f3-18ff-7be28bb5369f@andreasschulze.de:
Hello,
using slapo-ppolicy I could configure slapd to hash a password if it's sent unhashed.
moduleload ppolicy.la moduleload argon2.la password-hash {ARGON2}
database mdb suffix dc=test ... overlay ppolicy ppolicy_default "cn=default,ou=ppolicies,dc=test" ppolicy_hash_cleartext
That work and I could hash them using ARGON2.
But clients could still hash a password them self and write '{MD5}...' as userPassword for example. Is it possible to reject any userPasswords prefixed with hash schema?
But isn't the real question whether clients using MD5 can handle ARGON2?
Andreas
Am 01.12.21 um 08:00 schrieb Ulrich Windl:
But isn't the real question whether clients using MD5 can handle ARGON2?
Hello Ulrich,
no, it isn't. MD5 was an example only. mostly I see {SHA} and {SSHA}
Let me explain my understanding of operating an identity-provider.
- identity-provider = OpenLDAP-Server - service-provider = dovecot / apache/nginx for example - client = MUA / Webbrowser - any connections between client and service-provider as well as between service-provider and identity-provider is encrypted - service-provider validating a password get a plaintext password from a client and transfer it to the identity-provider The response is only Yes/No = password was right or wrong -> no service-provider must handle any hashing scheme for that job - service-provider setting a new password get a plaintext password from a client and transfer it to the identity provider -> no service-provider must handle any hashing scheme for that job - for the identity provider there are only two types of access to an attribute 'userPassword': compare/authenticate and write. User's passwords are always transferred un-hashed /to/ the identity-provider. - the identity-provider takes care for calculations and storage of that hash.
Is this model correct?
And as part of this model I like to avoid any service-provider write a local pre-hashed userPassword
Andreas
On 12/1/21 15:34, A. Schulze wrote:
Let me explain my understanding of operating an identity-provider.
- identity-provider = OpenLDAP-Server
- service-provider = dovecot / apache/nginx for example
Well, personally I'd avoid this terminology but well..
- client = MUA / Webbrowser
- any connections between client and service-provider as well as between service-provider and identity-provider is encrypted
Yepp, TLS everywhere!
- service-provider validating a password get a plaintext password from a client and transfer it to the identity-provider The response is only Yes/No = password was right or wrong -> no service-provider must handle any hashing scheme for that job
- service-provider setting a new password get a plaintext password from a client and transfer it to the identity provider -> no service-provider must handle any hashing scheme for that job
- for the identity provider there are only two types of access to an attribute 'userPassword': compare/authenticate and write. User's passwords are always transferred un-hashed /to/ the identity-provider.
- the identity-provider takes care for calculations and storage of that hash.
Is this model correct?
Yes, it is correct. One could argue that it's an unnecessary risk that services receive clear-text passwords from clients. Because if the service gets hacked you passwords can get stolen therein.
Possible risk mitigations: - additionally use one-time passwords - use OAuth 2.0 in services with short-term tokens
And as part of this model I like to avoid any service-provider write a local pre-hashed userPassword
I'd strongly recommend to disallow any service to write userPassword values by ACLs.
Instead use an isolated simple central password self-service web app which you can configure with really paranoid security settings (systemd sandboxing, AppArmor/SELinux, lean and secure coding, etc.).
Ciao, Michael.
openldap-technical@openldap.org
-
A. Schulze -
Dave Macias -
Michael Ströder -
Ulrich Windl