Séparez les violations de mot de passe la semaine dernière à LinkedIn, eHarmony et Last.fm a exposé des millions d’informations d’identification et a une fois de plus soulevé la question de savoir si une entreprise peut obtenir la bonne sécurité par mot de passe. Pour mieux comprendre pourquoi les entreprises continuent de commettre les mêmes erreurs et ce qu’elles pourraient faire différemment pour éviter de futures débâcles de mots de passe, j’ai interviewé Thomas H.Ptacekun chercheur en sécurité avec Matasano Sécurité.
Ptacek n’est que l’un des nombreux chercheurs extrêmement intelligents avec qui j’ai parlé de ce sujet. Voici quelques extraits d’une conversation que nous avons eue la semaine dernière.
MMA: je lisais juste un article par Eric Chabrow, qui a souligné que LinkedIn – une entreprise de plusieurs milliards de dollars qui détient des informations personnelles sur certains des dirigeants les plus importants au monde – n’a ni directeur de l’information ni directeur de la sécurité de l’information. Est-ce trop demander à une entreprise comme celle-ci de prendre la sécurité suffisamment au sérieux pour mieux protéger et sécuriser les mots de passe de ses utilisateurs ?
Ptacek : Il n’y a pas de corrélation entre la somme d’argent qu’une entreprise ou un service a ou reçoit – ou si c’est gratuit ou non – et la qualité de leurs pratiques de stockage des mots de passe. Personne ne comprend cela. Je pense que c’est un problème de développeurs généralistes qui écrivent des systèmes de stockage de mots de passe. Ce sont peut-être de bons développeurs, mais ils ne sont presque jamais des spécialistes du domaine de la sécurité. Il y a très peu de bons développeurs qui sont également des spécialistes du domaine de la sécurité. Donc, si vous êtes un développeur intelligent et talentueux, mais pas un spécialiste du domaine de la sécurité, et que vous devez mettre en place un système de stockage de mots de passe, même si ce n’est que MD5, pour vous, c’est une technologie extraterrestre de l’espace. C’est un algorithme cryptographique. Vous pouvez dire à votre patron qu’il s’agit d’un hachage cryptographique. Vous vous sentez bien sur le fait que vous stockez les mots de passe dans un hachage cryptographique. Mais vous devez être un expert du domaine pour savoir que le terme hachage cryptographique ne veut pas dire grand-chose.
MMA: Pourquoi le hachage cryptographique ne signifie-t-il pas grand-chose ? Peut-être que LinkedIn n’aurait pas dû utiliser une simple fonction de hachage cryptographique SHA-1, mais les développeurs ne devraient-ils pas chercher à sécuriser leurs mots de passe avec un algorithme cryptographique solide ?
Ptacek : Le mécanisme de base par lequel SHA-1 les mots de passe sont craqués, ou MD5 ou SHA-512 – peu importe l’algorithme que vous utilisez – n’a pas changé depuis le début des années 1990. Dès que le code pour implémenter SHA-1 est sorti, il était également disponible pour Jean l’Éventreur et d’autres outils de craquage de mot de passe. C’est une idée fausse très répandue – y compris parmi les responsables de la sécurité – que le problème ici est d’utiliser SHA-1. Cela n’aurait pas eu d’importance du tout s’ils avaient utilisé SHA-512, ils ne seraient pas mieux lotis du tout.
MMA: J’ai entendu des gens dire, vous savez que cela ne se serait probablement pas produit si LinkedIn et d’autres avaient salé les mots de passe – ou ajouté un peu d’aléatoire à chacun des mots de passe, forçant ainsi les attaquants à dépenser plus de ressources pour déchiffrer les hachages de mots de passe. Êtes-vous d’accord avec cela?
Ptacek : C’est en fait une autre idée fausse, l’idée que le problème est que les mots de passe n’étaient pas salés. Les mots de passe UNIX, et ils ont été salés pour toujours, depuis les années 70, et ils ont été piratés pour toujours. L’idée d’un sel dans votre mot de passe est une solution des années 70. Dans les années 90, lorsque les gens pénétraient par effraction dans les serveurs UNIX, ils volaient le fichier de mots de passe cachés et le cassaient. Invariablement, lorsque vous perdez le serveur, vous perdez les mots de passe sur ce serveur.
MMA: D’accord. Donc, si la faiblesse ne réside pas dans la force de l’algorithme cryptographique, ni dans le manque de sel ajouté aux mots de passe hachés, quelle est la réponse ?
Ptacek : Dans le cas de LinkedIn, et de nombreux autres sites, le problème est qu’ils utilisent le mauvais type d’algorithme. Ils utilisent un hachage cryptographique, lorsqu’ils ont besoin d’utiliser un hachage de mot de passe.
MMA: Je vais mordre : Quelle est la différence ?
Ptacek : La différence entre un hachage cryptographique et un hachage de stockage de mot de passe est qu’un hachage cryptographique est conçu pour être très, très rapide. Et ce doit être parce qu’il est conçu pour être utilisé dans des choses comme IPsec. Paquet par paquet, chaque fois qu’un paquet atteint une carte Ethernet, ce sont des choses qui doivent fonctionner assez rapidement pour n’ajouter aucune latence perceptible au trafic passant par les routeurs Internet et des choses comme ça. Et donc l’objectif principal de la conception des hachages cryptographiques est de les rendre rapides comme l’éclair.
Eh bien, c’est le contraire de ce que vous voulez avec un hachage de mot de passe. Vous voulez qu’un hachage de mot de passe soit très lent. La raison en est qu’un utilisateur normal se connecte une ou deux fois par jour si cela – peut-être qu’il a mal saisi son mot de passe et qu’il doit se connecter deux fois ou autre. Mais dans la plupart des cas, il y a très peu d’interactions que l’utilisateur normal a avec un site Web avec un hachage de mot de passe. Très peu de frais généraux liés à l’exécution d’une application Web proviennent du hachage de votre mot de passe. Mais si vous pensez à ce qu’un attaquant doit faire, il a un fichier plein de hachages et il doit essayer des millions de combinaisons de mots de passe contre chacun de ces hachages. Pour eux, si vous faites en sorte qu’un hachage de mot de passe prenne plus de temps, c’est un meurtre pour eux.
Donc, si vous utilisez un hachage de mot de passe moderne – même si vous êtes accéléré par le matériel, même si vous avez conçu vos propres circuits pour faire le hachage de mot de passe, il existe des hachages de mot de passe modernes et sécurisés qui prendraient des centaines ou des milliers d’années pour tester les mots de passe.
MMA: Pouvez-vous me donner un exemple de la différence entre le temps et les ressources qu’il faudrait pour craquer, par exemple, un mot de passe SHA-1 par rapport à un bon hachage de mot de passe ?
Ptacek : Disons que vous avez un mot de passe raisonnablement correct et que vous utilisez un hachage SHA-1 salé et aléatoire. Je peux, sur étagère, construire un système qui essaiera plusieurs, plusieurs dizaines de milliers de mots de passe possibles par seconde. Je peux aller chez Best Buy ou autre et acheter une carte standard qui le fera, et le logiciel pour le faire est open source.
Si nous utilisions plutôt quelque chose comme Bcryptce qui aurait simplement été la différence d’utiliser un autre [software] Lorsque j’ai construit mon application, je peux configurer Bcrypt pour qu’une seule tentative – pour tester si mon mot de passe était « password » ou « himom » – juste ce test pourrait prendre cent millisecondes. Donc, tout à coup, vous parlez de dizaines d’essais par seconde, au lieu de dizaines de milliers.
Ce que vous faites avec un hachage de mot de passe, c’est que vous le concevez de la manière opposée à la conception d’un hachage cryptographique standard. Un hachage cryptographique veut faire le minimum de travail possible afin d’arriver à un résultat sécurisé. Mais un hachage de mot de passe veut délibérément être conçu pour faire le maximum de travail.
Pouvez-vous expliquer en termes simples ce qui fait qu’un hachage de mot de passe comme Bcrypt prend tellement plus de temps à se fissurer ?
Ptacek : C’est similaire à si vous disiez, prenons le mot de passe SHA-1, mais au lieu d’utiliser simplement SHA-1, exécutons SHA-1 sur lui-même des milliers de fois. Donc, nous prendrons la sortie de SHA-1 et la renverrons à SHA-1, et nous le ferons des milliers et des milliers de fois, et vous saurez seulement si votre hachage de mot de passe est correct, lorsque vous regardez le résultat de cette 1 000e course SHA-1. Donc, pour que ce hachage de mot de passe fonctionne, vous devez exécuter l’algorithme 1 000 fois pour chaque supposition. C’est à peu près la tactique utilisée par les hachages de mots de passe modernes et sécurisés. Ce sont des algorithmes conçus pour que vous ne puissiez pas arriver au résultat sans beaucoup, beaucoup de travail. Je veux dire, nous parlons d’environ 100 millisecondes [one-tenth of a second] la peine de travailler sur du matériel moderne pour obtenir les résultats d’une seule tentative de mot de passe.
MMA: Alors, quel est le problème ici ? Ces systèmes de hachage de mot de passe sont-ils plus difficiles ou plus coûteux à déployer ?
Ptacek : C’est une question de connaissance. C’est plus facile à déployer qu’à construire soi-même. Si vous le construisez vous-même, cela demande beaucoup d’efforts. Alors que les bibliothèques pour sécuriser les hachages de mot de passe, là où vous les déposez, c’est comme un appel de fonction. Et ils sont tous gratuits. Il n’y a pas de brevets à craindre ou quoi que ce soit du genre.
L’application Web augmente très, très légèrement ses coûts. Une quantité imperceptible. Mais intelligemment, ils l’ont fait d’une manière qui fait exploser considérablement les coûts pour les attaquants. Si une tentative de mot de passe normal prend une microseconde [one millionth of a second]- mais un essai de mot de passe bcrypt prend 10 millisecondes [a hundredth of a second] – autant abandonner. Cela prendra des années et des années.
Disons que nous avons une application Web qui a perdu 10 millions de hachages de mot de passe, mais ce sont des mots de passe cryptés. Donc, je pense que dans ce dernier vidage que nous avons vu du vidage LinkedIn, environ trois millions de ces mots de passe avaient été piratés. C’était vraiment rapide et facile de voir si votre mot de passe s’y trouvait. Dans ce cas, si nous perdons 10 millions de mots de passe cryptés, au lieu que 3 millions d’entre eux soient publiés et compromis, vous pourriez voir des dizaines ou des centaines de mots de passe d’utilisateurs compromis. Parce que vous pourriez peut-être rechercher efficacement chaque mot de passe qui était « mot de passe », mais vous ne pouviez certainement plus utiliser un dictionnaire pour chaque mot de passe.
MMA: N’est-il pas probable que de nombreuses entreprises qui s’appuient sur des hachages cryptographiques ne soient pas passées aux hachages de mots de passe parce que cela pourrait être perturbateur, coûteux ou difficile à faire ? Êtes-vous d’accord, ou y a-t-il d’autres problèmes qui vous gênent ici ?
Ptacek : À un certain point, le coût de la migration est incroyablement élevé. Et la sécurisation d’applications Web aussi complexes que LinkedIn est un problème incroyablement difficile. En même temps, essayer de trouver des talents pour s’assurer qu’ils le construisent correctement… il n’y a tout simplement pas assez de talents en sécurité des applications. Il est difficile d’embaucher des gens qui savent de quoi ils parlent. Il y a tellement de connaissances en vrac qui se substituent à une véritable expertise. Vous pouvez trouver beaucoup de développeurs généraux partageant leur sagesse sur la façon de développer des applications sécurisées, mais ce ne sont en gros que des développeurs généraux essayant d’être intelligents, ce ne sont pas des gens qui savent vraiment de quoi ils parlent.
Pour moi, le problème fondamental, ce sont les mots de passe. Les gens devraient utiliser de meilleurs algorithmes de stockage s’ils veulent infliger des mots de passe à leurs utilisateurs. Ils devraient faire un meilleur travail. Mais la vraie réponse réside dans des choses comme l’authentification à deux facteurs avec les téléphones intelligents. L’authentification à deux facteurs me semble être la réponse. Je pense que dans dix ans, ce sera une approche commune.