Cette problématique est régulièrement rencontrée dès lors qu’une entreprise ou qu’un client s’engage dans un process IAM. L’idée est de mettre en place un référentiel unique, type LDAP/AD, comprenant de manière centralisée tous les comptes utilisateurs (internes / externes / prestataires) afin de les gérer à un seul et unique endroit.

Les avantages de cette gestion centralisée sont multiples :

• Facilité des workflow et process pour les départs, les arrivées, les mutations
• Application d’une politique de mot de passe centralisée
• Centralisation des crédentiels
• Intégration plus simple d’une solution d’IAM, de SSO, d’authentification-forte, de fédération, etc.
• Facilité des revues de comptes, de la gestion des comptes à privilèges, d’analyse et SoD.

Seulement, pour disposer d’un référentiel autoritaire et centralisé renfermant tous les comptes utilisateurs, il faut rapatrier et consolider ces informations en provenance de multiples référentiels.

Il n’est pas rare d’observer une entreprise-cliente qui démarre un projet IAM de zéro, et possède une multitude d’annuaires LDAP de technologies différentes (OpenLDAP, 398DS, SunDS, OpenDS, ADAM/ADLDS, ActiveDirectory, etc.). En parallèle, de nombreuses applications utilisées par les employés de cette même entreprise (internes, externes, prestataires) utilisent des bases de données SQL type MySQL, OracleDB, SQL Server, etc.

Une des tâches en amont d’un projet IAM est donc de consolider ces objets, ces identités, ces comptes, ces groupes, ces droits dans un référentiel LDAP unique. 

Ce qui nous amène à nous poser la question de la synchronisation et de l’import des mots de passe, toujours problématique.

Les mots de passe sont très rarement “en clair” dans les annuaires ou les bases de données. Malheur à ceux les conservant sans les hacher : c’est une très mauvaise pratique. Un password est généralement haché avant d’être stocké. Le hachage consiste à générer une empreinte unique (sous réserve de collision) associée au mot de passe initial. C’est cette empreinte qui est stockée, ainsi le mot de passe initial n’est jamais révélé. A partir de l’empreinte, il est impossible (mathématiquement parlant) de retrouver le mot de passe en clair originel, ce sont des fonctions à sens unique. Le hachage est donc un mécanisme de sécurité pour le stockage des mots de passe à imposer en toutes circonstances.

Plusieurs algorithmes existent et produisent des empreintes de différentes tailles avec des consommations en ressources différentes. Communément on cite les algorithmes suivants pour ce qui est du hachage de mot de passe :

• MD4 : obsolète
• MD5 : obsolète
• SHA1 : en voie d’obsolescence / obsolète
• SHA 256 / 384 / 512 : nouvelles normes / standard

A ces algorithmes peuvent s’ajouter des mécanismes additionnels pour renforcer l’algorithme de hachage :

• Le salage (salt) : ajout d’un aléa permettant d’augmenter la taille du mot de passe initial et d’en complexifier sa casse. Le salt doit être conservé en clair en parallèle de l’empreinte. Il permet de contrecarrer les attaques par rainbow-table (exemple SSHA, SMD5, BCRYPT). Les empreintes d’un même mot de passe sont donc toutes différentes puisque le salt varie à chaque fois.
• Le bouclage (looping) : pourquoi hacher une unique fois un mot de passe en quelques ms voire µs alors que hacher en boucle un mot de passe et ses empreintes permet d’augmenter le temps de cassage?
  • Par exemple : hash = md5(“password”) se calcule disons en 1ms (temps arbitraire)
  • hash = “password”; for(i=0;i<1000;<i++) hash = md5(hash);, le mot de passe est haché en boucle 1000 fois en (1ms x 1000) soit 1s
  • Si un assaillant tente une attaque brute-force sur l’empreinte finale, chaque test de brute-force sera réalisé en 1s plutôt qu’en 1ms, et donc rallongera considérablement le temps de cryptanalyse renforçant ainsi la confidentialité du mot de passe.

Passons à un cas pratique : imaginez une entreprise qui a centralisé tout ses annuaires LDAP de technologies hétérogènes en un seul et unique annuaire. Seulement, il reste des comptes d’utilisateurs non-importés dans cet annuaire unique et qui sont séquestrés dans une base de données SQL. Au regard du grand nombre de ces utilisateurs (plusieurs centaines par exemple), il est impensable pour l’entreprise de forcer tout ses utilisateurs à réinitialiser leur mot de passe afin que le nouveau mot de passe soit provisionné dans l’annuaire autoritaire.