Le mot de passe constitue l’un des piliers majeurs de la sécurité informatique. C’est pourquoi tant de pirates essayent de l’obtenir par des moyens toujours plus imaginatifs et complexes. Il représente le vecteur “ce que je sais” qui, combiné à un nom d’utilisateur, suffit pour s’authentifier sur la plupart des ordinateurs et systèmes d’information. Finalement, un mot de passe ne permet pas de donner directement des droits d’accès, mais d’assurer l’imputabilité lors de l’usage de ces droits.

Identification et authentification

L’identification et l’authentification sont deux notions différentes bien que liées. On parle d’identification lorsque l’on répond à la question “Qui suis-je ?”. On comprend vite qu’il est tout à fait possible de fausser la réponse en donnant une identité volée ou inventée. Le mot de passe joue alors le rôle d’authentifiant. Il apporte la preuve que l’identifiant fourni appartient bien à son propriétaire légitime, sous réserve évidemment qu’il soit le seul à le connaître. C’est là qu’on réalise l’importance d’avoir un mot de passe qui ne ressemble pas à celui du voisin.

La double authentification : une histoire de facteurs

L’authentification double facteur, souvent abrégé 2FA ou MFA, ajoute une couche de sécurité supplémentaire puisqu’il s’agira d’attester son identité en fournissant, en plus du classique mot de passe, un autre facteur idéalement de nature différente afin de lever toute ambiguïté d’identité.

Il existe quatre natures de facteurs :

  • la connaissance d’un secret (mot de passe, phrase de passe, code à usage unique…),
  • la possession d’un composant de sécurité (token USB, carte à puce, authentifieur physique…),
  • l’inhérence c’est-à-dire les caractéristiques physiques propres à une personne (empreinte digitale, rétinienne, irienne…),
  • la localisation (connexion d’un périphérique à un réseau localisé, position par satellites…). Ce dernier facteur est peu rencontré à cause des possibilités de contournement et de la faible maturité des technologies pouvant l’exploiter.

Certains services laissent aux utilisateurs finaux le choix du second facteur qu’ils souhaitent configurer, parmi lesquels figurent les dispositifs électroniques physiques comportant un composant de sécurité. Il s’agit d’équipements physiques indépendants, équipés d’un contrôleur dédié et d’une mémoire protégée, destinés à effectuer des opérations sensibles dans un environnement de confiance. Ils permettent de stocker et de manipuler des clés cryptographiques de manière sécurisée en empêchant leur extraction et leur duplication.

La vérification de l’identité par biométrie est, quant à elle, probabiliste. Il s’agira toujours de minimiser le taux de fausses acceptations (FAR pour False Acceptance Rate ou Taux de Faux Positif) et en parallèle maximiser la praticité en maintenant un taux bas de rejets à tort (FRR pour False Rejection Rate ou Taux de Faux Négatif). Problème : diminuer le FAR (ce qui revient à être plus strict) va mécaniquement augmenter le FRR, donc laisser des personnes légitimes sur la touche. Et oui, les algorithmes biométriques ne sont pas parfaits… Le point de croisement des deux courbes donne le Equal Error Rate, que l’on cherchera à diminuer le possible en jouant sur les paramètres de ces algorithmes.

L’authentification forte

D’un point de vu sémantique, on utilisera plutôt le terme d’authentification forte lorsqu’un moyen cryptographique est employé sous la forme d’un facteur de possession ou de connaissance. La plupart des mécanismes d’authentification forte reposent sur des protocoles dits de “challenge-réponse”. Pour faire simple, le serveur authentifiant envoie une question aléatoire au demandeur qui est l’unique personne à en connaitre la réponse, prouvant ainsi son identité.

Les phrases de passe

En remplacement des sempiternels mots de passe, ont peut choisir d’adopter des phrases de passe, habituellement plus longues. Elles peuvent contenir des symboles, des chiffres et des lettres sans pour autant être grammaticalement correctes. Pour un humain, les phrases de passe sont plus faciles à retenir qu’une combinaison désordonnée de symboles et de caractères alphanumériques. Cette caractéristique permet d’augmenter la taille des phrases de passe sans difficulté de mémorisation.

Voici trois exemples de phrases de passe :

  • " Je suis le seul à connaître mon mot de passe :) “, non aléatoire donc facile à retenir mais pas si compliqué à deviner pour un humain,
  • " fm-poing-zones-rabbin-aider-mime-poli-petit-dynamo “, une suite de mots aléatoires issus du dictionnaire français qui, mis bout à bout, ne veulent rien dire,
  • " xisik-tatoh-luzyp-vafep-cydon-byvek-hygux “, une suite de mots inventés mais prononçables (pseudowords).

Que l’on préfère les mots de passe ou les phrases de passe, les bonnes pratiques restent identiques : plus c’est long et aléatoire, mieux c’est. Par conséquent, il est fondamental de bannir les citations et expressions publiques. Cependant, il va sans dire que plus le secret est long, moins il sera commode à utiliser. Il s’agit donc de trouver un juste équilibre entre sécurité et praticité.

Les recommandations de la CNIL et de l’ANSSI

L’ANSSI et la CNIL publient chacune leur guide de recommandations relatifs aux moyens d’authentification. En tant qu’autorité française de protection des données (CHAPITRE VI du RGPD ), la CNIL a adapté celui de l’ANSSI à destination des responsables de traitements. Elle rappelle que d’après une étude menée par le groupe américain Verizon Communications en 2021, 81 % des notifications de violations de données mondiales seraient liées à une problématique de mots de passe. Par conséquent, tout le monde convient de l’importance de respecter les conseils de ces deux organisations face aux attaques par recherche exhaustive (dont “password spraying”), par dictionnaire, par tables pré-calculées (dont “rainbow tables”) ou encore par ingénierie sociale (dont hameçonnage). J’ai tenté de compiler ces bonnes pratiques dans ce document annexé à ce billet ainsi que dans le tableau ci-dessous.

Résumé en chiffres

Exigence Valeur
Entropie minimale sans mécanisme de défense d’accès 80 bits
Entropie minimale avec mécanisme de défense (temporisation, blocage, CAPTCHA) 50 bits
Entropie minimale des seconds facteurs (SMS, PIN…) 13 bits
Taille maximale autorisée >= 50 caractères
Validité lien unique de création/modification <= 24 heures
Longueur du sel aléatoire par compte >= 128 bits
Jeu de caractères à accepter >= 90
Entropie minimale avec un jeu de 90 caractères pour des données peu sensibles >= 65 bits
Entropie minimale avec un jeu de 90 caractères pour des données moyennement sensibles >= 85 bits
Entropie minimale avec un jeu de 90 caractères pour des données très sensibles >= 100 bits
Fréquence de renouvellement pour les comptes à privilèges [1 an; 3 ans]

NIST SP-800-63-4

Le National Institute of Standards and Technology (NIST) est une agence du département du Commerce des États-Unis d’Amérique. Dans sa mission de promotion de l’économie, elle conseille et développe pour les industries américaines mais aussi pour les agences fédérales, des standards technologiques. Le 21 août 2024, le NIST a publié le second draft public de la quatrième révision de ses guides en quatre volumes sur l’identité numérique, le (NIST SP 800-63 ). Concernant les apports de la version précédente (NIST SP-800-63-3 ), je vous renvoie vers l’ancienne version de ce billet disponible ici .

Les 114 pages du nouveau draft (NIST SP 800-63B ) couvrant un périmètre bien plus large que les recommandations CNIL et ANSSI, je vous recommande ce résumé en vidéo .

Calcul de l’entropie d’un mot de passe

L’entropie d’un mot de passe, exprimé en bits, désigne son niveau d’imprédictibilité. Ainsi, plus son entropie est élevée plus il est robuste. Un mot de passe qui aurait fuité d’une base de données ou qui aurait été précalculé dans un dictionnaire public verrait son entropie chuter à 0 bit. Les multiples outils qui promettent de calculer l’entropie d’un mot de passe n’expriment qu’une estimation de celle-ci puisque le jeu de symboles utilisables lors de sa génération lui est inconnu. Qui plus est, certains ne testent pas leur présence dans les dictionnaires. Le gestionnaire de mots de passe Keepass estime que la chaîne “pikach” a une entropie de 29 bits contre 12 bits pour “pikachu” alors qu’un caractère est ajouté, ce qui est contre-intuitif. Ceci est normal puisque “pikachu” est un nom propre susceptible d’être présent dans les dictionnaires. En réalité, l’entropie de ce mot de passe devrait être de 0 bit.

\(\small n\) bits d’entropie signifie qu’il faut en moyenne \(\small 2^{n-1}\) tentatives à un attaquant pour identifier le bon mot de passe. L’entropie est calculée avec la formule suivante :

\[\begin{aligned} \small E=log_2(R^{L}) \end{aligned}\]

Avec :

  • \(\small E\) entropie du mot de passe généré aléatoirement,
  • \(\small R\) nombre de caractères uniques dans le jeu,
  • \(\small L\) nombre de caractères dans le mot de passe.

Exemple de calcul pour un mot de passe aléatoire

Prenons le mot de passe “8Q-hH5-$G.H”, composé de 11 caractères sélectionnés parmi un jeu de 94 caractères. On a donc \(\small R=94\) et \(\small L=11\).

\[\begin{aligned} \small E=log_2(94^{11}) \end{aligned}\]\[\begin{aligned} \small E=log_2(5062982072492057196544) \end{aligned}\]\[\begin{aligned} \small E=72.1 \end{aligned}\]

Ce mot de passe a donc une entropie de 72 bits. Un attaquant devra donc en moyenne tester \(\small 2^{72-1}=2 361 183 241 434 822 606 848\) mots de passe avant de tomber sur le nôtre.

Cas des phrases de passe

L’entropie d’une phrase de passe aléatoire est calculée avec la même formule, mais les variables sont différemment utilisées :

  • \(\small R\) nombre de mots uniques dans le jeu du dictionnaire,
  • \(\small L\) nombre de mots dans la phrase de passe.

Prenons la phrase de passe “pipe-outthink-sense-luncheon-concave-raids”, composé de six mots sélectionnés aléatoirement dans un dictionnaire de 18635 mots anglais. On a donc \(\small R=18635\) et \(\small L=6\).

\[\begin{aligned} \small E=log_2(18635^{6}) \end{aligned}\]\[\begin{aligned} \small E=log_2(41877079123497226654515625) \end{aligned}\]\[\begin{aligned} \small E=85.1 \end{aligned}\]

Cette phrase de passe de passe a donc une entropie de 85 bits.

Exemple d’estimation du temps de cassage

Disons qu’un attaquant, qui aurait récupéré une base de données contenant des mots de passe hashés avec SHA-1, est actuellement capable de calculer 51 milliards de hashes SHA-1 à la seconde grâce à son GPU RTX 4090 dernier cri. Si le mot de passe recherché a une entropie de 72 bits, il faudra en théorie \(\small 2^{71}\) opérations avant de trouver la bonne correspondance soit en moyenne 1468 ans. Une base de données conservant des mots de passe simplement hashés en SHA-1 ne devrait pas exister. D’une part, l’ajout de sel empêche les attaques par tables pré-calculées et d’autre part SHA-1 n’est pas une fonction “memory-hard”.

Focus sur les “rainbow tables”

Les tables pré-calculées “rainbow tables” sont des structures de données inventées par Philippe Oechslin de l’Institut Fédéral Suisse de Technologie à Lausanne en 2003. Il s’agit en fait d’une amélioration des compromis temps-mémoire proposés par Martin Hellman dans les années 1980 (oui, le même Hellman que l’algorithme d’échange de clés Diffie-Hellman). Plus récemment Gildas Avoine de l’Institut National des Sciences Appliquées de Rennes, affina encore cette technique. Elles aident à diminuer le temps de comparaison des mots de passe en texte brut avec leur condensat.

Fonctionnement d’une “rainbow table”

On passe dans un premier temps le mot de passe en tête de chaîne \(\small P0\) dans une fonction de hachage. On obtient \(\small H(P0)\) que l’on envoie dans une première fonction de réduction \(\small R1\), ce qui aboutit à la création d’un nouveau mot de passe \(\small R1(H(P0))\) que l’on nomme \(\small P1\). On itère cette procédure un nombre fixé de fois afin de former une chaîne. Ainsi \(\small R2(H(P1))\) donne P2, \(\small R3(H(P2))\) donne \(\small P3\) etc… Une fonction de réduction transforme un condensat en un nouveau mot de passe. Elle change à chaque itération afin d’éviter les collisions.

Représentation d'une "rainbow table" simple avec trois fonctions de réduction différentes. Cette table simplifiée est composée de trois lignes et de sept colonnes. La première colonne est verte, la deuxième verte pâle, la troisième bleue, la quatrième bleue pâle, la cinquième rouge, la sixième rouge pâle et la dernière jaune. La première ligne commence pour le mot de passe "wikipedia". Il est ensuite passé dans la fonction de hachage pour être transformé en "ao4kd". Ce premier condensat est passé dans la fonction de réduction R1 qui donne un nouveau mot de passe "secret" lui-même repassé dans la fonction de hachage qui sort le condensat "9kpmw". Il est passé dans la fonction de réduction R2 pour aboutir au condensat "v0d$x". Enfin ce condensat est transformé en dernier mot de passe "rootroot" par la fonction de réduction R3. Sur la représentation deux autres lignes sont présentes. Le principe est identique mais les valeurs différentes. Le premier mot de passe de la deuxième ligne est "abcdefgh" et le dernier "myname". Quant à la troisième, on passe de "passwd" à "linux23". S'agissant d'un exemple technique, sollicitez l'aide d'un voyant.
Représentation d'une "rainbow table" simple avec trois fonctions de réduction différentes. – Source : wikipedia.org

Pour la première chaîne ci-dessus, seule la paire \(\small (P0, R3(H(P2))\) est stockée dans la table, à savoir wikipedia et rootroot. Le reste n’est pas conservé afin de limiter la mémoire nécessaire. Il est toutefois possible de retrouver le contenu intermédiaire en recalculant à la demande l’ensemble de la chaîne à partir du mot de passe en tête de chaîne c’est-à-dire \(\small P0\). Un grand nombre d’autres paires sont ensuite calculées en fournissant un autre \(\small P0\).

Exploitation d’une “rainbow table”

Comment exploiter une “rainbow table” afin de trouver le mot de passe correspondant à un condensat ? Pour bien comprendre, reprenons l’exemple illustré sur Wikipédia.

Représentation de l'exploitation d'une "rainbow table" sur trois lignes. Les étapes sont décrites dans l'explication ci-dessous. Il faut seulement noter que le bloc à gauche est composé de trois lignes sur deux colonnes. La première colonne est verte et contient les premiers mots de passe des trois lignes de la "rainbow table" précédente. La seconde colonne est jaune et contient les derniers mots de passe des trois lignes de la "rainbow table" précédente. S'agissant d'un exemple technique, solicttez un l'aide d'un voyant.
Fonctionnement d'une recherche simple en cinq étapes dans une "rainbow table". – Source : wikipedia.org
  1. On passe un condensat récupéré dans une base de donnée volée, ici “re3xes”, dans la dernière fonction de réduction utilisée lors de la création de la table, dans notre cas \(\small R3\). On regarde si le mot de passe généré “rambo” apparaît dans la dernière colonne de la table (mots de passe en jaune). Ce n’est pas le cas.
  2. On repasse “re3xes” dans l’avant dernière fonction de réduction utilisée, soit \(\small R2\). Elle donne en sortie le mot de passe “crypto”, qui n’apparait toujours pas dans la dernière colonne de la table. On hache ce nouveau mot de passe afin d’obtenir un condensat que l’on donne en entrée à la fonction de réduction \(\small R3\).
  3. Deux cas de figures se présentent alors : soit le mot de passe renvoyé par \(\small R3\) n’est pas présent dans la table, auquel cas on devra recommencer l’exercice en passant “re3xes” dans \(\small R1\) puis en itérant de la même façon jusqu’à \(\small R3\), soit le mot le mot de passe est présent dans la table. C’est le cas ici avec “linux23”.
  4. Quel est le mot de passe en tête de chaîne (mots de passe en vert) correspondant à “linux23” ? Il s’agit de “passwd”. Nous allons maintenant tenter de trouver le mot de passe dont le condensat est “re3xes”. On sait que c’est dans la dernière chaîne qu’on le trouvera le mot de passe à deviner. On hache donc “passwd” pour ensuite le passer dans la fonction de réduction \(\small R1\). Le mot de passe “culture” en sort, que l’on passe de nouveau dans la fonction de hachage. Enfin ! On retombe logiquement sur “re3xes”. On peut donc conclure que dans la base de données, le mot de passe non salé “culture” a pour condensat “re3xes”.

Stockage des mots de passe en base de données

Les attaques par tables pré-calculées, que sont typiquement les “rainbow tables”, sont inopérantes si les mots de passe sont stockés hashés et salés en base de données. Mais appliquer cette protection, ne doit pas être fait de façon approximative. Voici quelques conseils :

  • Chaque mot de passe doit être associé à un sel unique,
  • La longueur de ce sel doit être supérieure ou égale à 128 bits,
  • Le sel doit être fabriqué avec un générateur de nombre pseudo-aléatoire cryptographiquement sûr (CSPRNG),
  • Ne pas employer le nom d’utilisateur comme sel puisque qu’il est prédictible,
  • Les mots de passe doivent être hashés côté serveur,
  • Les fonctions de dérivation de clé recommandées (intégrant des fonctions de hachage cryptographiques) sont Argon2id > scrypt > bcrypt > PBKDF2 SHA-256,
  • Le sel doit être stocké dans la table des comptes utilisateurs avec leur condensat.

Outillage et documentation

  • Générateur libre et robuste de mots passe d’Aaron Toponce : https://atoponce.github.io/webpassgen/ . Comme indiqué par Aaron, il ne faut jamais faire confiance à un générateur en ligne. C’est pourquoi, il convient de déconnecter la machine génératrice pendant son utilisation.
  • Le plus connu de tous les gestionnaires libres de mots de passe développé par Dominik Reichl : https://keepass.info . KeePass est navivement capable de générer HOTP et TOTP. Des pièces jointes peuvent être ajoutées aux entrées. Elles seront chiffrées au même titre que les mots de passe.
  • Un module d’extension KeePass afin d’exposer la base de données localement par une interface RPC : https://github.com/kee-org/keepassrpc . Couplé au module d’extension navigateur https://www.kee.pm , vos mots de passe seront disponibles directement dans votre navigateur préféré.
  • Gestionnaire de mots de passe libre pour les équipes développé au Luxembourg : https://www.passbolt.com
  • “Temps nécessaire à un pirate pour brute forcer votre mot de passe en 2024” https://www.hivesystems.com/blog/are-your-passwords-in-the-green est le titre de la dernière synthèse documentaire annuelle proposée par Hive Systems détaillant le niveau de robustesse de votre mot de passe. La méthodologie pour arriver à ces résultats y est bien expliquée.
  • Une page très complète sur l’intérêt du sel dans le stockage des mots de passe associé aux meilleures pratiques : https://crackstation.net/hashing-security.htm