AES crypte-t-il un mot de passe avec lui-même plus sûr que SHA1?
Ce n'est pas vraiment une question pratique, mais plutôt une question de curiosité. J'ai entendu un professeur CS recommander de passer des mots de passe md5ing non pas à SHA1, mais à AES cryptant le mot de passe en se servant de la clé. Quelqu'un a-t-il une idée de savoir si cela est réellement plus ou moins sûr?
Quelques réflexions à ce sujet:
- SHA1 est unidirectionnel, ce qui devrait le rendre plus sécurisé qu'une fonction qui préserve les données.
- D'un autre côté, le pirate ne peut pas profiter de la nature déchiffrable d'AES car il ne connaît pas encore le mot de passe.
- A moins qu'il ne le devine. Mais alors il serait dans n'importe comment je l'ai chiffré.
- Comme vous savez que le mot de passe AES est déchiffré lorsque la clé de déchiffrement correspond à la sortie, il peut être brutalisé sur l'ordinateur du pirate.
- Mais le pirate ne sait pas comment il est crypté, donc il n'essaierait pas cela.
- Mais le pirate aurait également pu obtenir le code de cryptage, auquel cas il s'agit simplement de savoir quelles données prennent plus de temps à la force brute.
- La plupart des sites Web utilisent md5 ou sha1 (non?), Donc les tables de recherche pour ces hachages seraient beaucoup plus répandues que pour la méthode AES. Rendant ainsi la méthode AES plus sûre.
- Mais si nous salions les deux méthodes, elles deviendraient également immunisées contre les tables de recherche.
Quelques points communs dans les réponses et contre-points:
Le cryptage AES n'est pas conçu pour être résistant aux collisions, et il y aura donc probablement plus de collisions pour la même longueur de chaîne de hachage.
Si nous utilisons un sel plus long, le mot de passe crypté sera plus long qu'un hachage SHA1. Cela peut être suffisant pour ramener les collisions à un niveau comparable - ou peut-être pas.
Le cryptage AES vous indique la durée du mot de passe, dans les 16 octets.
Nous pouvons ajouter à la méthode AES: après l'avoir chiffrée, nous garnissons ou découpons à une longueur raisonnable (qui est plus longue que SHA1 afin d'éviter les collisions).
Réponse courte: mauvaise idée, ne le faites pas.
Réponse plus longue: le but de l'exercice est de stocker quelque chose qui permet au serveur de vérifier un mot de passe donné, mais ne lui permet pas de reconstruire le mot de passe; cette dernière propriété est souhaitable, de sorte que les conséquences d'un accès en lecture illégitime à la base de données du serveur par un attaquant restent limitées.
Nous voulons donc une transformation déterministe unidirectionnelle qui convertit un mot de passe donné en valeur de vérification. La transformation doit être:
- configurablement lent, afin de contrecarrer les attaques par dictionnaire;
- distinct pour chaque instance, pour empêcher les attaques de dictionnaires parallèles, y compris les tables précalculées (c'est de cela qu'il s'agit).
Une seule invocation de MD5 ou SHA-1 échoue sur les deux comptes, car ces fonctions sont très rapides et non salées. La lenteur peut se faire en imbriquant de nombreuses invocations (des milliers, voire des millions), et le sel peut être injecté "quelque part", bien qu'il existe de bonnes et de mauvaises façons de le faire. PBKDF2 est une transformation standard qui fait exactement cela, et elle n'est pas mauvaise (bien que bcrypt devrait être quelque peu préférable ).
Cependant, MD5 et SHA-1 font au moins une bonne chose: ils étaient conçus pour être à sens unique. C'est difficile à faire; il n'est même pas prouvé théoriquement que les fonctions à sens unique peuvent réellement exister. Les cryptographes du monde entier participent actuellement à une compétition pour concevoir une nouvelle fonction de hachage unidirectionnelle meilleure.
Donc, ce que votre professeur semble recommander, c'est de remplacer une fonction conçue pour unidirectionnelle, par une fonction qui était pas conçue pour unidirectionnel. Il ne corrige rien sur la lenteur et le salage, mais il supprime la seule bonne chose à propos de MD5 et SHA-1. De plus, AES est connu pour être relativement faible en ce qui concerne les attaques par clé associée - ce n'est pas un problème tant que AES est utilisé pour ce à quoi il était destiné, c'est-à-dire le cryptage, mais il devient un important problème quand il est subverti dans un bloc de construction pour une fonction de hachage à sens unique. Il semble possible de construire une fonction de hachage sécurisée en réutilisant des parties de la conception AES, mais cela nécessite une refonte substantielle (voir par exemple Whirlpool et ECHO ).
N'utilisez donc pas un schéma de hachage de mot de passe basé sur AES; d'ailleurs, n'utilisez rien de "fait maison": c'est la recette du désastre. La sécurité ne peut pas être testée; la seule façon connue de créer un algorithme sécurisé est de faire en sorte que des centaines de cryptographes formés l'examinent attentivement pendant quelques années. Vous ne pouvez pas le faire vous-même. Même un cryptographe seul ne risque pas cela.
Utilisez plutôt bcrypt. PBKDF2 n'est pas mal non plus.
La plupart des sites Web utilisaient md5 ou sha1 (non?), C'est donc ce à quoi un pirate s'attendrait. Rendant ainsi la méthode AES plus sûre.
Même si la plupart des sites Web utilisent MD5 ou SHA1, le passage à AES juste pour la raison qu'il n'est généralement pas utilisé là-bas ne le rendrait pas plus sûr - c'est juste sécurité par obscurité , ce qui ne contribue généralement pas efficacement à augmenter la sécurité; il sera beaucoup plus sûr d'utiliser un bon algorithme (qui est bien testé pour le but donné) et de le documenter publiquement, que d'utiliser un algorithme dont vous ne pouvez pas être sûr s'il est bon, et ne pas dire que vous êtes En l'utilisant.
Pour le moment, je peux penser aux inconvénients possibles suivants lors de l'utilisation d'AES ou de tout autre algorithme de cryptage comme celui-ci:
- Les algorithmes de chiffrement ne sont généralement pas conçus pour éviter les collisions: comme indiqué dans les commentaires ci-dessous, cela pourrait ne pas poser de problème en raison du comportement pseudo-aléatoire attendu du chiffrement par blocs. Mais encore, vous utilisez un algorithme de chiffrement pour quelque chose pour lequel il n'a pas été conçu.
- Il est imaginable qu'il y ait des attaques contre les algorithmes de cryptage qui sont beaucoup plus faciles à faire si l'on sait que le texte clair et le mot de passe sont en fait les mêmes (si le fait de l'algorithme que vous utilisez fuit d'une manière ou d'une autre, ce qui n'est pas si improbable étant donné que c'est par exemple discuté ici).
- Les algorithmes de chiffrement produisent des données qui, dans de nombreux cas, varient avec la longueur du texte en clair. Cela signifie que le texte chiffré contient des informations sur la longueur du mot de passe. Dans le cas d'AES, c'est un multiple de 16 octets pour autant que je sache ; les valeurs de hachage, en revanche, ont une taille fixe (par exemple 160 bits/20 octets pour SHA1); ce qui signifie qu'un pirate potentiel a une chance d'obtenir plus d'informations d'un texte chiffré que d'une valeur de hachage.
- En cryptographie, il est généralement toujours moins sûr de préparer quelque chose par vous-même (qui est ensuite probablement aussi uniquement utilisé par vous) que d'utiliser quelque chose qui est bien testé et qui existe depuis longtemps dans la communauté (ce qui signifie qu'il a eu le temps d'être soigneusement inspecté) par un certain nombre de cryptanalystes).
- Vous voulez vous assurer que votre algorithme de hachage de mot de passe est lent, afin que les attaquants potentiels soient empêchés de forcer leur chemin dans votre système. Une façon d'y parvenir consiste par exemple à effectuer de manière itérative le hachage en plusieurs tours, comme le fait par exemple PKBDF2. Pour plus de détails, voir http://security.blogoverflow.com/2013/09/about-secure-password-hashing/
Un problème immédiat que je vois avec cette approche est la longueur de clé fixe d'AES. En utilisant AES-128, un serait limité à 16 octets du mot de passe. Qu'en est-il des mots de passe plus longs ou des phrases de passe longues?
Pour s'adapter à n'importe quelle longueur de mot de passe, vous auriez besoin d'une fonction de hachage, revenez donc au point initial.
Notez qu'il existe des moyens bien étudiés et sécurisés * de transformer un chiffrement par blocs en une fonction de hachage, appelés modes PGV comme Davies-Meyer, Matyas-Meyer-Oseas ou Miyaguchi-Preneel.
(*) Pour une définition appropriée de "sécurisé".
Cependant, considérez ceci:
Je pénètre dans votre site et j'obtiens suffisamment d'accès pour remarquer que vous avez des clés AES configurées pour votre système, la seule chose qui semble "cryptée" est vos mots de passe ... devinez ce que je vais faire.
Je les garderais hachés, laisse beaucoup moins de place pour gratter facilement l'intégralité de votre base de données de mots de passe.
En plus de cela, en tant que propriétaire de site, je ne veux PAS pouvoir décrypter les mots de passe de mes utilisateurs en premier lieu, sinon l'option de "récupérer les mots de passe" devient une fonctionnalité possible que les plus hauts responsables peuvent demander, et techniquement, nous peut le faire parce que le système sous-jacent est construit à l'aide d'un système de chiffrement au lieu d'un système de hachage (une raison boiteuse mais les développeurs de logiciels traitent des demandes comme celles-ci).
Principalement: Lorsque la sécurité est concernée, n'essayez pas de faire quelque chose de farfelu et hors de la boîte, vous vous écrirez probablement un énorme trou de sécurité parce que vous ne pourrez pas mettre la quantité de recherche d'une équipe de personnes travaillant sur un algorithme dans un but précis devrait le faire.
La bonne réponse est: cela n'a pas vraiment d'importance du tout.
Dans le cas des mots de passe, la seule attaque pratique consiste à essayer une liste de mots de passe jusqu'à ce que vous trouviez le bon par force brute. Personne n'essaiera d'attaquer directement SHA1 ou AES pour le faire. Même dans le domaine de recherche actuel, attaquer SHA1 serait dix mille fois plus facile que AES, les deux sont encore complètement impossibles (pour inverser les hachages de mot de passe car les collisions n'ont pas d'importance ici). Et comme un chercheur trouve un autre moyen d'attaquer l'autre algorithme, les chances pourraient être inversées l'année prochaine.
Ce qui pourrait être important, c'est la vitesse à laquelle vous dérivez votre hachage/cryptez votre mot de passe. Mais si par exemple SHA1 est plus rapide et vous voulez qu'il soit plus lent (pour repousser les attaques par force brute), vous pouvez simplement hacher plusieurs fois.
Ce qu'un pirate "attend" n'est pas si pertinent, faire quelque chose "d'inattendu" n'est que de l'obscurité. C'est comme dire "J'inverse toutes les lettres de mot de passe, maintenant c'est plus sûr". Ce ne sera pas le cas. Si le pirate peut accéder à votre base de données de mots de passe, comment pouvez-vous être sûr qu'il n'a pas accès à votre fonction de dérivation de hachage de mot de passe?
Un défaut lors du "cryptage d'un mot de passe avec lui-même": la longueur du texte chiffré peut donner à l'attaquant un indice sur la longueur du mot de passe. C'est terrible.
Dans tous les cas, vous devez saler le mot de passe, de préférence avec quelque chose d'unique à l'utilisateur.
Il existe des MAC (Message Authentication Codes) construits à partir de chiffres de bloc; le plus connu est probablement CBC-MAC . Il a des problèmes par rapport à un hachage-mac, notamment:
Étant donné un chiffrement de bloc sécurisé, CBC-MAC est sécurisé pour les messages de longueur fixe. Cependant, en soi, il n'est pas sécurisé pour les messages de longueur variable. Un attaquant qui connaît les bonnes paires message-tag (c'est-à-dire CBC-MAC) (m, t) et (m ', t') peut générer un troisième message m '' dont CBC-MAC sera également t '.
[...]
Ce problème ne peut pas être résolu en ajoutant un bloc de taille de message (par exemple, avec le renforcement de Merkle-Damgård) et il est donc recommandé d'utiliser un mode de fonctionnement différent, par exemple, CMAC pour protéger l'intégrité des messages de longueur variable.
La réponse la plus courte: la sécurité d'un MAC construit à partir d'un chiffrement par bloc dépend de la façon dont vous le construisez. Une construction naïve aura presque certainement des défauts importants.
Le fait que vous ayez conçu un algorithme inhabituel ne le rend pas sûr. Les algorithmes "self made" sont dangereux, car personne n'en a effectué d'analyse cryptographique.
Comme @Thomas Pornin l'a écrit ci-dessus, AES n'a pas été conçu pour résister aux collisions. En outre, AES est relativement rapide, ce qui simplifie les attaques.
SHA1 est conçu pour résister aux collisions, mais SHA1 est également conçu pour être très rapide, car son but est de générer des hachages de gros volumes de données ou de fichiers en peu de temps. Son but n'est pas d'empêcher les attaques sur les mots de passe hachés.
Si vous souhaitez générer un hachage de mot de passe résistant à différents types d'attaques, pensez à l'étirement du mot de passe. En fonction de votre pile technologique et des bibliothèques disponibles, pensez à bcrypt, scrypt, argon2.