Schemeprefix is not detected correctly #16

New issue

Open

opened 2022-07-19 07:53:45 +00:00 by quentin · 0 comments

quentin commented

2022-07-19 07:53:45 +00:00

Owner

According to RFC2307 (do you know a better reference?), a password must be stored as follow:

userPassword values MUST be represented by following syntax:

    passwordvalue          = schemeprefix encryptedpassword
    schemeprefix           = "{" scheme "}"
    scheme                 = "crypt" / "md5" / "sha" / altscheme
    altscheme              = "x-" keystring
    encryptedpassword      = encrypted password

We observe that the proposed schemes are in lowercase and that the scheme we use are not referenced (SSHA, SSHA256 and SSHA512). Additionnaly, if Bottin does not detect any scheme it knows, it considers the password as plaintext and hash it with SSHA512.

It leads to the following quirks:

if you send a hash in lowercase like {ssha}xxx, it is silently considered as a plain text password and then re-hashed, thus preventing people from connecting.
if you send an unsupported hash, like {crypt}xxx, it is also silently ignored and considered as a plain text password.

Before patching Bottin, I have these 2 questions:

Do we want to handle plain text password?
Do we want to match the schemeprefix as "{" keystring "}", and if we match a keystring, always consider the input as a hash, and fails if the scheme corresponding to the keystring is not found?
Can we avoid crypt that is system dependant, is not recommended, and use instead PBKDF2 that is also recommended by 389DS, an LDAP implementation by Red Hat?

References:

My understanding of the problem:

SSHA512 is not a key derivation algorithm and thus is poorly suited for passwords
Crypt simply asks to forward the password to your crypt library that handle many different algorithms, including secure ones. This is system-dependant.
PBKDF2 is implemented as a community module in OpenLDAP, it is standard in 389DS
Argon2 has been merged in OpenLDAP core

Considering these facts, I think we should implement {ARGON2} directly instead of {CRYPT}.

According to RFC2307 (do you know a better reference?), a password must be stored as follow: ``` userPassword values MUST be represented by following syntax: passwordvalue = schemeprefix encryptedpassword schemeprefix = "{" scheme "}" scheme = "crypt" / "md5" / "sha" / altscheme altscheme = "x-" keystring encryptedpassword = encrypted password ``` We observe that the proposed schemes are in lowercase and that the scheme we use are not referenced (`SSHA`, `SSHA256` and `SSHA512`). Additionnaly, if Bottin does not detect any scheme it knows, it considers the password as plaintext and hash it with `SSHA512`. It leads to the following quirks: - if you send a hash in lowercase like `{ssha}xxx`, it is silently considered as a plain text password and then re-hashed, thus preventing people from connecting. - if you send an unsupported hash, like `{crypt}xxx`, it is also silently ignored and considered as a plain text password. Before patching Bottin, I have these 2 questions: - Do we want to handle plain text password? - Do we want to match the schemeprefix as "{" keystring "}", and if we match a keystring, always consider the input as a hash, and fails if the scheme corresponding to the keystring is not found? - Can we avoid `crypt` that is system dependant, is not recommended, and use instead PBKDF2 that is also recommended by 389DS, an LDAP implementation by Red Hat? References: - [OpenLDAP SHA-2 Module](https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/passwd/sha2/README) - [389DS Password Upgrade](https://directory.fedoraproject.org/docs/389ds/design/pwupgrade-on-bind.html) - [OpenLDAP crypt](https://www.openldap.org/faq/data/cache/344.html) - [OpenLDAP PBKDF2](https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/passwd/pbkdf2) - [OpenLDAP Argon2 on Debian](https://manpages.debian.org/testing/slapd-contrib/slapd-pw-argon2.5.en.html) - [OpenLDAP Argon2 support in source code](https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/pwmods/README.argon2) My understanding of the problem: - SSHA512 is not a key derivation algorithm and thus is poorly suited for passwords - Crypt simply asks to forward the password to your crypt library that handle many different algorithms, including secure ones. This is system-dependant. - PBKDF2 is implemented as a community module in OpenLDAP, it is standard in 389DS - Argon2 has been merged in OpenLDAP core Considering these facts, I think we should implement `{ARGON2}` directly instead of `{CRYPT}`.