Vous n’avez pas pu passer à côté de la nouvelle, et encore moins de tout le tapage qui a suivi la faille de sécurité qui a touché Adobe en octobre 2013.

A ce jour, c’est non seulement la fuite de données utilisateurs la plus importante, avec plus de 150 000 noms révélés, mais également la plus gênante.

Cette fuite de données a révélé qu’Adobe stockait les mots de passe de ses utilisateurs de façon complètement inconsidérée. Ceci s’est révélé d’autant plus surprenant qu’il aurait été très facile de les stocker de façon bien plus sécurisée.

A la suite de l’article nakedsecurity (non traduit malheureusement) dans lequel nous détaillions où Adobe avait fait des erreurs, nombres de nos lecteurs nous ont posé la question suivante : « Et si vous nous expliquiez comment stocker les mots de passe correctement ? »

Mettons d’ores et déjà les choses au clair : cet article n’est pas un cours de programmation ponctué d’exemples de code que vous pouvez répliquer et utiliser sur votre serveur.

Premièrement, nous ne savons pas si vous utilisez PHP, MySQL, C#, Java, Perl ou Python etc. Ensuite, il existe une multitude d’articles qui vous diront quoi faire avec vos mots de passe.

Nous, nous avons choisi de vous expliquer.

Essai 1 : stockez des mots de passe non chiffrés

Pour cette mission, il est important de ne pas vous faire voler les mots de passe utilisateurs. Vous pourriez ainsi être tenté de conserver votre base de données utilisateurs, sous cette forme, utilisable rapidement et facilement :

Si votre réseau n’est pas très étendu et composé de quelques utilisateurs que vous connaissez bien et pour lesquels vous assurez le support en personne, vous irez peut-être même jusqu’à considérer comme un avantage de stocker les mots de passe de façon non chiffrée.

Ainsi, si l’un d’entre eux oublie son mot de passe, il vous suffit de le consulter et de le communiquer à l’intéressé.

Nous vous le déconseillons pour une raison très simple : toute personne qui verra le fichier pourra s’identifier à la place de n’importe quel utilisateur.

Pire encore, si cette personne arrive à apercevoir de quoi est composé le mot de passe de tel utilisateur, celle-ci aura facilement accès aux différents comptes de cet utilisateur.

Prenons Alfred pour exemple : il a choisi son prénom suivi d’une série de nombres. David a choisi une date dont la signification est probablement personnelle. Le mot de passe d’Eric Cleese est en lien avec les Monty Pythons, alors que Charlie et Duck n’y ont pas vraiment prêté attention.

Nous souhaitons insister sur le fait que ni vous, ni aucun administrateur système ne devrait pouvoir voir, même par erreur, un mot de passe utilisateur.

Ce n’est pas une question de confiance. Il s’agit de l’essence même de l’expression mot de passe. Celui-ci doit être considéré comme un PIN, à savoir un numéro d’identification personnelle, qui ne regarde personne d’autre que l’intéressé.

Essai 2 – chiffrez les mots de passe dans la base de données

Chiffrer les mots de passe est une bien meilleure option.

Vous pouvez même mettre en place une clé de déchiffrement pour la base de données stockée sur un autre serveur, demander à votre serveur de validation des mots de passe d’aller la récupérer uniquement quand cela est nécessaire, et ainsi ne jamais la garder en mémoire.

Les mots de passe utilisateurs ne sont donc jamais écrits de façon non-chiffrée sur un disque. Il est impossible de les apercevoir accidentellement dans la base de données et s’ils étaient dérobés, ils seraient inexploitables pour les voleurs.

C’est cette option qu’Adobe a choisi et le tout ressemblait, à peu de choses près, à ça :

→ Pour l’ensemble de données ci-dessus, nous avons choisi la clé DESPAIR et avons chiffré chacun mot de passe avec le standard DES. Le recours à DES, pour n’importe quelle situation de la vie réelle, n’est pas franchement une bonne idée. Celui-ci utilise en effet une clé 56-bits ou composée de sept caractères. Bien que la clé 56-bits sache générer plus 100 000 millions de mots de passe différents, les outils de cracking modernes savent déchiffrer une quantité aussi élevée de mot de passe chaque jour.

Vous pensez peut-être que se tourner vers ce type de chiffrement symétrique sera intéressant pour vous, car il vous donne la possibilité de rechiffrer automatiquement tous les mots de passe de la base de données, même si vous décidez de changer la clé (certaines de vos politiques l’exigent peut-être même) ou de mettre en place un algorithme plus sécurisé pour lutter contre les outils de cracking.

Cependant, nous vous conseillons de ne pas chiffrer les bases de données de mots de passe de façon réversible.

Le problème que nous avons évoqué dans l’essai numéro un (à savoir que ni vous, ni aucun administrateur réseau ne doit pouvoir récupérer un mot de passe utilisateur) n’est  toujours pas résolu.

Pire encore, si les criminels parviennent à la fois à s’emparer de votre base de données et à récupérer les mots de passe, en se connectant, par exemple, à votre serveur à distance, l’essai numéro deux devient l’essai numéro un.

Au passage, les mots de passe figurant ci-dessus posent également un autre problème : nous avons utilisé le DES de façon telle que le même mot de passe produit à chaque fois la même donnée.

Il est donc possible de déduire automatiquement que Charlie et Duck partagent le même mot de passe, sans même une clé de déchiffrement. Cette fuite d’information est inutile : aussi inutile que de savoir que la longueur de la donnée chiffrée nous permet de deviner la longueur du mot de passe non chiffré.

Il est donc important d’insister sur les recommandations suivantes :

1. Les mots de passe utilisateurs ne doivent pas pouvoir être récupérés dans la base de données
2. Les mots de passe identiques ou même ressemblants doivent avoir être hachés différemment
3. La base de données ne doit en aucun cas donner des indications sur la longueur de mots de passe.

Essai 3 – sectionner les mots de passe

Notre recommandation numéro 1 est la suivante : « les mots de passe utilisateurs ne doivent pas pouvoir être récupérés dans la base de données »

A première vue, cela nécessite une espèce de chiffrement « non réversible », qui paraît soit impossible, soit inutile.

Ceci est cependant possible en mettant en place un hachage cryptographique, qui combine une longueur au hasard et mélange le tout.

En s’exécutant, l’algorithme porte avec lui une quantité fixe de données aléatoire de sortie : ceci donne un hachage qui jouera le rôle d’empreinte digitale pour les données en entrée.

Mathématiquement parlant, le hachage est une fonction unidirectionnelle : vous pouvez mettre en place un hachage sur n’importe quel message mais vous ne pouvez pas revenir en arrière, dans le sens hachage final vers la donnée d’entrée.

Un hachage cryptographique est conçu pour résister aux tentatives, même volontaires, de détournement via le mélange, le déchiquetage ou la liquéfaction de sa donnée d’entrée pour qu’en théorie, il soit impossible :

• De créer un dossier comportant un hachage prédéfini par tout autre facteur que le hasard
• De trouver deux dossiers qui « coïncident » à savoir, qui partagent le même hachage (quel qu’il soit) via tout autre facteur que le hasard
• De deviner, à partir du hachage en lui-même,  quoi que ce soit concernant la structure de la donnée d’entrée, comme sa longueur, par exemple.

Les algorithmes les plus connus et les plus répandus sont MD5, SHA-1 et SHA-256. [Note de @JeromeVosgien] Je vous recommande l’article de mon homologue Jean-François Audenard chez Orange Business Services.

Parmi eux, MD5 est celui dont l’algorithme permet le moins de « mélange-déchiquetage-liquéfaction ». Ainsi, il est possible de trouver beaucoup plus facilement deux dossiers comportant le même hachage par erreur.

MD5 ne remplit donc pas sa mission cryptographique première. Ainsi, nous vous déconseillons de l’utiliser pour tout nouveau projet.

SHA-1 et MD5 sont assez semblables. De nombreux spécialistes pensent d’ailleurs que SHA-1 posera bientôt les mêmes problèmes que MD5, donc choisissez plutôt de ne pas l’utiliser.

Nous choisirons d’utiliser SHA-256, ce qui, appliqué directement à notre donnée échantillon donne le résultat ci-dessous (le hachage a été tronqué pour entrer dans le graphique)

Les hachages sont tous de la même longueur. Ainsi, aucune donnée concernant la taille des mots de passe ne peut fuiter.

De plus, comme nous pouvons prévoir la quantité de données que nous devrons stocker pour chaque mot de passe, limiter la longueur d’un mot de passe utilisateur paraît absolument inutile (toutes les valeurs SHA-256 font 256 bits ou 32 octets).

→ Il est tout à fait acceptable d’être exigeant en ce qui concerne la longueur des mots de passe, soit 128 ou 256 caractères, pour empêcher les mécontents de surcharger vos serveurs avec des quantités  lourdes de  données. Cependant, les limites sont telles qu’un mot de passe n’excédant pas 16 caractères est extrêmement restrictif et doit être évité.

Afin de vérifier un mot de passe utilisateur au moment de l’authentification, il suffit de conserver le mot de passe soumis en mémoire. Ainsi, il n’entre jamais en contact avec le disque et calcule lui-même son hachage.

Si le hachage calculé correspond au hachage stocké, alors l’utilisateur présente bel et bien du bon mot de passe et on peut le laisser s’identifier.

Cependant, le troisième essai n’est toujours pas satisfaisant. En effet, Charlie et Duck partage le même hachage. On est donc en mesure de savoir qu’ils ont choisi le même mot de passe.

En effet, le texte du mot de passe se présentera toujours ainsi 5E884898DA28..EF721D1542D8, à chaque fois que quelqu’un le choisira.

En d’autres termes, les voleurs peuvent tout à fait mettre en place un tableau de pré-calcul de hachage des mots de passe les plus utilisés, ou même, à condition d’avoir suffisamment d’espace sur le disque, pré-calculer tous les mots de passe jusqu’à une certaine longueur, et ainsi craquer tout mot de passe figurant sur leur liste en regardant simplement la base de données.

Essai 4 : saler et hacher

Pour chaque mot de passe, il existe une possibilité d’adaptation du hachage. Cela consiste à y ajouter de la donnée appelée « sel ». On l’appelle ainsi car elle permet d’assaisonner le hachage en sortie.

Le sel est également parfois appelé nonce, soit l’acronyme de « number used once » (un nombre utilisé une seule fois).

Plus simplement, il s’agit de générer un ensemble aléatoire d’octets que l’on intègre au calcul de hachage avec le mot de passe actuel.

Le plus simple est de déposer le sel devant le mot de passe et hacher la chaîne de texte combiné.

Le sel n’est pas une clé de chiffrement. Ainsi, il peut être stocké dans la base de données de mots de passe avec les noms d’utilisateurs. Il est utile pour empêcher un hachage similaire à deux utilisateurs partageant le même mot de passe.

Pour que cela arrive, les utilisateurs devraient partager à la fois le même mot de passe et le même hachage. Ainsi, en utilisant des clés de 16 octets ou en « salant » davantage, les chances que cela se produise sont infimes.

Voici ce à quoi ressemble désormais notre base de données (les sels de 16 octets et les hachages ont été tronqués pour rentrer dans le cadre).

Dans cette liste, les hachages, représentés par les champs à la fin de chaque ligne, sont calculés grâce à une chaîne de texte composée de salt et suivie du mot de passe. Le hachage SHA-256 est calculé, ainsi les deux mots de passe de Charlie et Duck sont désormais totalement différents.

Assurez-vous d’opter pour des salts aléatoires. N’utilisez jamais un contre comme 000001, 000002,  et ainsi de suite. N’ayez pas non plus recours à un générateur de code aléatoire de mauvaise qualité comme  C’s random().

Si vous prenez cette option, votre salt correspondra peut-être à ceux localisés dans une autre base de données de mots de passe, et quoi qu’il arrive, un pirate pourra le deviner.

En intégrant suffisamment d’octets provenant d’une source fiable de génération de nombres aléatoires (si vous le pouvez, utilisez CryptoAPI sur Windows ou /dev/urandom sur les systèmes UNIX), vous aurez la garantie que chaque salt est bel et bien unique et que celui-ci est bien un « number used once » (nombre utilisé une seule fois).

Alors, nous y sommes ?

Presque, mais pas totalement encore.

Bien que nous ayons satisfaits à nos trois exigences de base (pas de réversibilité, pas de répétition dans le hachage et pas de possibilité de deviner la longueur des mots de passe), le hachage pour lequel nous avons opté, un simple SHA-256 de salt + mot de passe, se calcule très rapidement.

En effet, les serveurs de cracking des hachages de moins de 20 000 euros savent traiter jusqu’à 100 000 000 000 SHA256 chaque seconde, voire plus.

Il convient de ralentir un peu pour stopper les crackers.

Essai 5 : étendre le hachage

Par nature, le hachage cryptographique empêche les pirates de revenir en arrière. Cependant, avec un peu de chance et un mauvais choix de mot de passe, ces derniers peuvent souvent arriver au même résultat en tentant d’avancer encore et encore.

En effet, si les escrocs parviennent à s’emparer de votre base de données de mots de passe et à travailler hors ligne, la seule limite est le processeur et la vitesse à laquelle ce dernier leur permettra de deviner les mots de passe et leur hachage.

Nous entendons par cela qu’ils peuvent essayer de mélanger tous les mots de passe du dictionnaire (ou tous les mots de passe de AA..AA à ZZ..ZZ) à tous les salts contenus dans votre base de données, de calculer tous les hachages possibles et de voir si cela donne des résultats probants.

De plus, les dictionnaires de mots de passe, les algorithmes conçus pour générer des mots de passe de cracking ont l’air d’être tous organisés de la même façon : pour que les mots de passe les plus utilisés se détachent le plus rapidement possible.

Cela signifie que les mots de passe peu originaux seront probablement crackés plus tôt.

→ Il est important de savoir que même avec un million de million de hachages de mots de passe testés par seconde, un mot de passe bien choisi restera indétectable plus ou moins indéfiniment. Il existe plus d’un millier de millions de millions de millions de mot de passe à 12 caractères reposant sur la chaine de caractères A-Za-z0-9

Ainsi, il parait sensé de ralentir les attaques hors ligne en intégrant notre algorithme de hachage des mots de passe à une boucle nécessitant des milliers de calculs de hachages individuels.

Ainsi, la vérification individuelle d’un mot de passe ne sera pas aussi lente au moment de l’authentification et l’utilisateur ne s’en plaindra pas. Il ne le remarquera même pas.

Cependant, cela permettra de réduire les possibilités d’attaques hors ligne, proportionnellement aux nombres d’itérations choisies.

Malgré tout, pour la répétition de hachage, ne tentez pas d’inventer votre propre algorithme.

Optez pour l’un de ces algorithmes connus : PBKDF2, bcrypt ou scrypt

Nous vous recommandons PBKDF2 dans ce cas, car il est basé sur des règles basiques de hachage, conformes à des nombreuses normes nationales et internationales.

Nous vous recommandons également de le coupler à l’algorithme de hachage HMAC-SHA-256, répété 10 000 fois ou plus.

HMAC-SHA-256 est une méthode spécifique d’utilisation de l’algorithme SHA-256 qui n’est pas qu’un simple hachage, mais qui permet au hachage d’être totalement intégré à une clé ou un salt.

• Prenez une clé aléatoire ou un salt K, mélangez-y quelques octets et vous obtenez K1
• Calculez le hachage SHA-256 de K1 auquel s’ajoute votre donnée et obtenez H1
• Enlevez à K un autre ensemble d’octets et obtenez K2
• Calculez le hachage SHA-256 de K2 et de H1 et obtenez le hachage définitif, H2

En d’autres termes, vous hachez une clé plus votre message, puis hachez de nouveau une version permutée de la clé et du premier hachage.

Dans PBKDF2 avec 10 000 itérations, nous fournissons à HMAC-SHA256 le mot de passe utilisateur accompagné de notre salt et faisons de lui le premier de 10 000 boucles.

Puis, nous recommuniquons le mot de passe accompagné du hachage HMAC précédemment calculé à HMAC-SHA-256 pour les 9999 boucles restantes.

A chaque boucle, la dernière sortie est XORed, accompagnée de la précédente. Ainsi, on conserve un « hash accumulator » actif. Puis, lorsque le process touche à sa fin, l’accumulateur devient le hachage PBKDF2.

Il nous faut maintenant ajouter, dans notre base de données, le comptage des itérations, le salt et le hachage final PBKDF2.

Les capacités de calcul des pirates augmentant, vous avez la possibilité d’accroître le nombre d’itérations que vous souhaitez utiliser, en doublant le comptage chaque année, par exemple.

Si un collaborateur s’identifie avec succès via un hachage quelque peu « vieillot », il vous suffit de regénérer et de mettre à jour le hachage, via un nouveau comptage des itérations. (Seule une identification utilisateur réussie peut vous permettre de connaître le mot de passe exact d’un utilisateur).

Pour les utilisateurs qui ne se sont pas authentifiés depuis longtemps et dont les hachages vous paraissent peu sûrs, il vous suffit de désactiver les comptes et de les forcer à réinitialiser leur mot de passe, à la prochaine authentification.

Pour finir

Voici un résumé de nos recommandations de base pour un stockage sécurisé des mots de passe utilisateur :

• Utilisez un générateur de nombres aléatoires performant pour créer un salt de 16 octets ou plus
• Intégrez le salt et le mot de passe à l’algorithme PBKDF2
• Utilisez HMAC-SHA-256 comme hachage de base au sein de PBKDF2
• Décidez de 10 000 itérations ou plus (novembre 2013)
• Optez pour un débit de 32 octets (256 octets) à partir de PBKDF2 pour le hachage final du mot de passe
• Sauvegardez le comptage des itérations, le salt et le hachage final dans votre base de données de mots de passe
• Augmentez régulièrement le comptage des itérations pour pouvoir faire face aux outils de cracking les plus rapides

Quoi qu’il arrive, n’essayez pas de mettre en place votre propre algorithme de stockage.

Pour Adobe, cela ne s’est pas très bien fini et il y a peu de chance que ça se termine bien pour vous.

Billet inspiré de Serious Security: How to store your users passwords safely, parPaul Duclin, Sophos nakedsecurity.