2:34 p.m.
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
3:37 p.m.
Look up olcPPolicyHashCleartext
On Nov 26, 2021, 5:35 PM -0500, A. Schulze <sca(a)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
3:50 p.m.
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.
12:31 p.m.
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
11 p.m.
New subject: Antw: [EXT] ppolicy-question
>> "A. Schulze" <sca(a)andreasschulze.de> schrieb
am 26.11.2021 um 23:34 in
Nachricht
<a8e1310c-2367-34f3-18ff-7be28bb5369f(a)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
6:34 a.m.
New subject: Antw: [EXT] ppolicy-question
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
8:27 a.m.
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.
482
days inactive
487
days old
openldap-technical@openldap.org
6 comments
4 participants
participants (4)
-
A. Schulze -
Dave Macias -
Michael Ströder -
Ulrich Windl