Pourquoi SHA-256 n'est pas bon pour les mots de passe?
Je viens de commencer à apprendre tout cela et je ne trouve vraiment aucune réponse à cela, à savoir pourquoi SHA-256 n'est pas utilisé pour les mots de passe? J'ai trouvé que la raison en est que parce que le SHA-256 normal est une fonction rapide, et qu'il vaut mieux en utiliser des plus lentes, mais voici la partie que je n'ai pas vraiment, d'après ce que j'ai lu jusqu'à présent, SHA-256 produit un hachage qui prendrait BEAUCOUP d'années pour se fissurer, comme BEAUCOUP BEAUCOUP, alors pourquoi est-il considéré comme mauvais pour les mots de passe alors qu'il est pratiquement impossible de le cracker?
Il s'agit de réduire le risque global de perte. Un bon algorithme de hachage ne permet pas d'inverser la valeur de hachage pour calculer le texte d'origine. Cependant, les mots de passe sont très, très courts. En faisant une supposition sur un mot de passe, l'attaquant peut comparer la sortie de son SHA-256 avec le SHA-256 qu'il trouve dans la base de données. Et parce que les mots de passe sont si courts, tester de nombreuses suppositions de mots de passe de cette façon est facile pour un ordinateur. Pour quelques milliers de dollars, vous pouvez acheter un petit supercalculateur dédié aux tests SHA-256 (utilisé pour le minage de bitcoins), qui permet à un attaquant de tester 16 trillions mot de passe différents par seconde. C'est beaucoup plus efficace que d'essayer de casser SHA-256.
Le hachage de mots de passe ne consiste pas à empêcher la fissuration d'un seul mot de passe. Les propriétaires de sites Web sont beaucoup plus inquiets car ils ont une base de données d'un million d'utilisateurs, et lorsque les attaquants s'introduisent, ils volent fréquemment une copie de la base de données des mots de passe. Ils veulent empêcher l'attaquant de casser tous les mots de passe de leur base de données.
Avec le matériel dédié (ou un tableau de zombies de botnet), un attaquant peut facilement casser la grande majorité des mots de passe dans une base de données typique où ils ne sont protégés que par une seule itération de SHA-256. Et briser les mots de passe sur un site permet aux attaquants de profiter des personnes qui réutilisent leurs mots de passe sur plusieurs sites. Il s'agit d'un précurseur des attaques ATO (Account Take Over), où ils réutilisent les mots de passe volés pour accéder à des comptes bancaires ou à des cartes-cadeaux et volent de l'argent réel.
Pour se défendre contre cela, un algorithme de protection de mot de passe spécialement conçu est construit comme une perte de temps. Par exemple, PBKDF2 exécute un algorithme de hachage des centaines, des milliers ou des millions de fois, selon la façon dont vous le configurez. Cela augmente la quantité de travail qu'un attaquant doit faire pour exécuter un seul test par ce facteur important. Si vous définissez PBKDF2 pour exécuter un million d'itérations, cela réduirait l'efficacité de la boîte ci-dessus à tester seulement 16 millions de tentatives de mot de passe par seconde. Un attaquant ne pourrait briser qu'un millionième des mots de passe de la base de données par rapport au craquage d'une base de données où ils étaient stockés en tant que SHA-256 unique. Voilà la réduction des risques.
En plus de l'excellente réponse de John, il y a une autre chose importante à considérer.
Lors de la vérification d'un mot de passe, beaucoup de temps est consacré à des actions comme la recherche des informations de compte stockées (nom d'utilisateur, mot de passe) dans une base de données.
Si vous disposez d'un algorithme de hachage rapide, cette recherche occupe désormais une partie importante de la validation de votre mot de passe. Cela rend relativement facile pour un intrus de lancer une attaque où il tire simplement des noms et des mots de passe aléatoires et détermine quels noms plutôt que mots de passe n'existent pas en chronométrant les réponses.
En hachant lentement le mot de passe entrant avant de l'envoyer à la base de données pour comparaison avec le mot de passe stocké, vous réduisez la durée de la recherche dans la base de données et de la comparaison des mots de passe du temps nécessaire à la vérification des mots de passe. Le résultat est qu'une recherche échouée prend désormais le même temps (dans la marge de latence du réseau, etc.) qu'une réussite.
Bien sûr, cela suppose que vous hachiez le mot de passe entrant avant d'essayer de récupérer les informations utilisateur. Si vous ne le faites pas, un échec pour un utilisateur inexistant serait beaucoup plus rapide qu'un échec pour un utilisateur existant avec un mauvais mot de passe, donnant à la personne qui attaque votre système des informations potentielles sur les tentatives qu'il a faites. noms d'utilisateur réels, même s'il ne savait pas que c'était des noms d'utilisateur réels pour commencer.
Cela se produit-il dans la pratique? Aucune idée. Mais c'était l'une des raisons de la lenteur des mécanismes de hachage que notre équipe pentest nous a dit il y a plusieurs années.