• Origine : RFC2307 (person), RFC4519
• Nom : userPassword
• Description : Mot de passe
• OID : 2.5.4.35
• Attribut parent : aucun
• Valuation : multivalué
• ObjectClass : inetOrgPerson, supannApplication
• Obligatoire : non
• Type de donnée : chaîne d'octets (max. 128)
• Règles de comparaison : égalité

• Type d'usage: authentification
• Contexte d'utilisation : LDAP
• Unicité : non
• Visibilité : secret
• Indexation recommandée : aucune
• Voir aussi : userCertificate

Si utilisé, cet attribut DOIT contenir une ou plusieurs valeur(s) permettant d'authentifier, par validation d'un mot de passe, la personne ou l'application représentée par l'objet courant.

En cas de valeurs multiples, chaque valeur correspond à un mot de passe indépendant. L'authentification est considérée comme fructueuse si l'une des valeurs valide le mot de passe.

Cet attribut est en général exploité directement par le serveur LDAP lors d'une requête BIND à l'annuaire.

Considérations de sécurité :

• Les mots de passe NE DOIVENT PAS être stockés en clair dans l'attribut, afin de pas être facilement récupérables en cas de compromission de la base LDAP. Dans ce but, il est recommandé de les hacher ou chiffrer en utilisant l'un des schémas de stockage supportés par le serveur LDAP et répondant aux normes actuelles de cryptographie. Le plus courant est d'utiliser une fonction de dérivation des clés prévue à cet effet telle que argon2, PBKDF2, bcrypt ou scrypt. Les fonctions historiques de hachage MD5, SHA-1 ou même SHA-2 ne suffisent plus à protéger les mots de passe en 2021.

• Ils ne DOIVENT PAS circuler en clair sur le réseau. Tout « bind » non anonyme doit s'effectuer sur un canal sécurisé, typiquement chiffré via TLS (StartTLS ou LDAPS), ou utiliser un mécanisme SASL n'impliquant pas l'envoi du mot de passe lui-même du client au serveur. En OpenLDAP, le critère “ssf” (Security Strength Factor) peut être utilisé dans les ACLs afin de bloquer les connexions ne respectant pas les contraintes minimales de sécurité.

• L'attribut DOIT être protégé par une configuration appropriée des ACLs LDAP (contrôles d'accès) limitant son accès aux seuls besoins de l'authentification et du changement de mot de passe.

• Le mot de passe PEUT alternativement être géré par un serveur d'authentification externe (exemple: KDC Kerberos), en utilisant la délégation d'authentification SASL. Dans ce cas les valeurs du userPassword sont de simples pointeurs qui ne contiennent pas de secrets.

Références :

• Recommandations de l'OWASP sur le stockage des mots de passe
• Guide selection crypto de l'ANSSI cf §4.8 Mécanismes de hachage de mot de passe

Personne dont le mot de passe est haché via la fonction crypt() du système hébergeant le serveur LDAP, en utilisant la fonction SHA-512 (de la famille SHA-2) avec le nombre de tours par défaut :

dn: uid=dgaudin,ou=people,dc=univ-exemple,dc=fr
userPassword: {CRYPT}$6$ZYq8PJHtLTWky6dg$mPQ6WlzP4YUwxCfqX3XJrtCYsu3lqOShu2bYK4/oaTU41cW9vShpRbszUkSd6Y7mjljzzbN/KosmhwwhdBjot1

Personne dont le mot de passe est haché avec l'algorithme Argon2 (supporté par OpenLDAP à partir de la version 2.4.50):

dn: uid=paranoia,ou=people,dc=univ-exemple,dc=fr
userPassword: {ARGON2}$argon2id$v=19$m=32768,t=2,p=2$c2FsdHNhbHRzYWx0c2FsdA$oPP9ajWig+LxlrqRNDDRu7Q7ChehrZJNmnAHjaupR60

Personne dont le mot de passe est validé par un serveur Kerberos du realm UNIV-EXEMPLE.FR (moyennant configuration SASL appropriée) :

dn: uid=toto,ou=people,dc=univ-exemple,dc=fr
userPassword: {SASL}toto@UNIV-EXEMPLE.FR