Schemeprefix is not detected correctly #16

Open
opened 7 months ago by quentin · 0 comments
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}`.
quentin added the
bug
label 7 months ago
quentin changed title from Schemeprefix is not detected correctly and lead to wrong logic to Schemeprefix is not detected correctly 7 months ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/bottin#16
Loading…
There is no content yet.