Combien de temps forcer brutalement un hachage salé SHA-512? (sel fourni)
Voici un algorithme en Java:
public String getHash(String password, String salt) throws Exception {
String input = password + salt;
MessageDigest md = MessageDigest.getInstance(SHA-512);
byte[] out = md.digest(input.getBytes());
return HexEncoder.toHex(out);
}
Supposons que le sel est connu. Je veux savoir le temps qu'il faut pour forcer brutalement lorsque le mot de passe est un dictionnaire et que ce n'est pas un dictionnaire.
Dans votre cas, casser l'algorithme de hachage équivaut à rechercher une collision dans l'algorithme de hachage. Cela signifie que vous n'avez pas besoin de trouver le mot de passe lui-même (ce qui serait une attaque par pré-image ), vous avez juste besoin de trouver une sortie de la fonction de hachage qui est égale à celle d'un mot de passe valide ( donc "collision"). La recherche d'une collision à l'aide d'un attaque d'anniversaire prend O (2 ^ (n/2)) fois, où n est la longueur de sortie de la fonction de hachage en bits.
SHA-2 ayant une taille de sortie de 512 bits, la recherche d’une collision prendrait donc O (2 ^ 256) fois. Étant donné qu’il n’ya pas d’attaque intelligente sur l’algorithme lui-même (actuellement, la famille de hachage SHA-2 n’est pas connue), c’est ce qu’il faut pour casser l’algorithme.
Pour avoir une idée de ce que 2 ^ 256 signifie réellement: actuellement, on pense que le nombre d'atomes dans l'univers (entier !!!) est d'environ 10 ^ 80, ce qui correspond à environ 2 ^ 266. En supposant une entrée de 32 octets (ce qui est raisonnable pour votre cas - sel de 20 octets + mot de passe de 12 octets), ma machine prend ~ 0,22s (~ 2 ^ -2s) pour les calculs de 65 536 (= 2 ^ 16). Donc, 2 ^ 256 calculs seraient effectués en 2 ^ 240 * 2 ^ 16 calculs qui prendraient
2^240 * 2^-2 = 2^238 ~ 10^72s ~ 3,17 * 10^64 years
Même appeler cela des millions d'années est ridicule. Et cela ne va pas beaucoup mieux avec le matériel le plus rapide de la planète, qui calcule des milliers de hachages en parallèle. Aucune technologie humaine ne sera en mesure de réduire ce nombre à une valeur acceptable.
Alors oubliez brusquement le SHA-256 ici. Votre prochaine question portait sur les mots du dictionnaire. Pour récupérer des mots de passe aussi faibles Les tables Rainbow ont été utilisés traditionnellement. Une table Rainbow est généralement juste une table de valeurs de hachage précalculées. L’idée est que si vous pouviez pré-calculer et stocker chaque hachage possible avec son entrée, cela vous prendrait O(1) rechercher un hachage donné et en extraire une pré-image valide (bien entendu, cela n’est pas possible dans la pratique car il n’existe aucun périphérique de stockage capable de stocker une telle quantité de données. Ce dilemme est appelé compromis temps-mémoire . Comme vous ne pouvez stocker que tant de valeurs, les tables Rainbow incluent une chaîne d'enchaînement avec des fonctions de réduction intermédiaires (ceci est expliqué en détail dans l'article de Wikipédia) pour économiser de l'espace en économisant un peu de temps. .
Les sels étaient une contre-mesure pour rendre de telles tables Rainbow irréalisables. Pour décourager les attaquants de précalculer une table pour un sel spécifique, il est recommandé d'appliquer des valeurs de sel par utilisateur. Cependant, étant donné que les utilisateurs n'utilisent pas de mots de passe sécurisés et complètement aléatoires, il est toujours surprenant de constater le succès que vous pouvez obtenir si le sel est connu et vous ne faites qu'itérer sur un grand dictionnaire de mots de passe courants dans un schéma simple d'essai et d'erreur. La relation entre le langage naturel et le caractère aléatoire est exprimée sous la forme entropie . Les choix de mot de passe typiques sont généralement d'entropie faible, alors que les valeurs complètement aléatoires contiennent un maximum d'entropie.
La faible entropie des mots de passe classiques permet à l'un de vos utilisateurs d'utiliser un mot de passe provenant d'une base de données relativement petite contenant des mots de passe courants. Si vous les recherchez sur Google, vous finirez par trouver des liens torrentaux pour ces bases de données de mots de passe, souvent dans la catégorie de la taille en gigaoctets. Le succès avec un tel outil est généralement compris entre quelques minutes et quelques jours si l’attaquant n’est soumis à aucune restriction.
C'est pourquoi généralement le hachage et le salage ne suffisent pas, vous devez également installer d'autres mécanismes de sécurité. Vous devez utiliser une méthode de réduction de l'entropie ralentie artificiellement, telle que PBKDF2, décrite dans PKCS # 5 , et vous devez imposer une période d'attente à un utilisateur donné avant qu'il ne puisse réessayer d'entrer son mot de passe. Un bon schéma consiste à commencer par 0,5 seconde, puis à doubler cette durée pour chaque tentative infructueuse. Dans la plupart des cas, les utilisateurs ne le remarquent pas et n'échouent pas plus de trois fois en moyenne. Mais cela ralentira considérablement tout outsider malveillant qui tentera d’attaquer votre application.
Je veux savoir le temps qu'il faut pour forcer brutalement lorsque le mot de passe est un dictionnaire et que ce n'est pas un dictionnaire.
Mot de passe du dictionnaire
Ballpark chiffre: il y a environ 1 000 000 mots anglais, et si un pirate informatique peut calculer environ 10 000 hachages SHA-512 par seconde ( mise à jour: voir le commentaire de CodesInChaos, cette estimation est très basse), 1 000 000/10 000 = 100 secondes . Il faudrait donc un peu plus d'une minute pour déchiffrer un mot de passe du dictionnaire d'un seul mot pour un seul utilisateur. Si l'utilisateur concatène deux mots du dictionnaire, vous êtes dans l'espace de quelques jours, mais cela est tout à fait possible si l'attaquant se soucie suffisamment. Plus que ça et ça commence à devenir dur.
Mot de passe aléatoire
Si le mot de passe est une suite véritablement aléatoire de caractères alphanumériques (majuscules et minuscules), le nombre de mots de passe possibles de longueur N est alors égal à 60 ^ N . (il y a 60 caractères possibles). Nous ferons le calcul dans l'autre sens cette fois-ci; nous demanderons: Quelle longueur de mot de passe pourrions-nous déchiffrer étant donné une durée spécifique? Utilisez simplement cette formule:
N = Log60(t * 10,000) où t est le temps nécessaire pour calculer les hachages en secondes (en supposant que 10 000 hachages par seconde sont utilisés).
1 minute: 3.2
5 minute: 3.6
30 minutes: 4.1
2 hours: 4.4
3 days: 5.2
Donc, étant donné 3 jours, nous serions en mesure de déchiffrer le mot de passe s'il comporte 5 caractères.
Tout cela est très difficile, mais vous voyez l'idée. Mise à jour: voir le commentaire ci-dessous, il est en fait possible de déchiffrer des mots de passe beaucoup plus longs que cela.
Que se passe t-il ici?
Éclaircissons certaines idées fausses:
Le sel ne ralentit pas le calcul des hachages , cela signifie simplement qu'ils doivent déchiffrer individuellement le mot de passe de chaque utilisateur et les tables de hachage pré-calculées (buzz). -Word: Les tables Rainbow) sont totalement inutiles. Si vous n'avez pas de table de hachage précalculée et que vous ne craignez qu'un mot de passe haché, le salage ne fait aucune différence.
SHA-512 n'est pas conçu pour être difficile à brute-force . De meilleurs algorithmes de hachage tels que BCrypt, PBKDF2 ou SCrypt peuvent être configurés pour prendre beaucoup plus de temps à calculer, et un ordinateur moyen pourrait ne pouvoir calculer que 10-20 hache une seconde. Lisez Cette excellente réponse à propos du hachage du mot de passe si vous ne l'avez pas déjà fait.
update: comme écrit dans le commentaire de CodesInChaos, même les mots de passe à entropie élevée (environ 10 caractères) pourraient être renforcés si le matériel approprié était utilisé pour calculer les hachages SHA-512.
Notes sur la réponse acceptée:
La réponse acceptée à partir de septembre 2014 est incorrecte et dangereusement incorrecte:
Dans votre cas, casser l'algorithme de hachage équivaut à rechercher une collision dans l'algorithme de hachage. Cela signifie que vous n'avez pas besoin de trouver le mot de passe lui-même (ce qui serait une attaque de pré-image) ... La recherche d'une collision à l'aide d'une attaque d'anniversaire prend un temps O (2 ^ n/2), où n est la longueur de sortie du hachage fonction en bits.
L'attaque de l'anniversaire est complètement hors de propos à craquer un hash donné. Et c’est en fait un exemple parfait d’une attaque de pré-image. Cette formule et les deux paragraphes suivants donnent des valeurs dangereusement élevées et totalement dénuées de sens pour un temps d'attaque. Comme démontré ci-dessus , il est parfaitement possible de déchiffrer les mots de passe des dictionnaires salés en quelques minutes .
La faible entropie des mots de passe habituels rend possible un risque relativement élevé que l'un de vos utilisateurs utilise un mot de passe provenant d'une base de données relativement petite contenant des mots de passe communs ...
C'est pourquoi généralement le hachage et le salage ne suffisent pas, vous devez également installer d'autres mécanismes de sécurité. Vous devez utiliser une méthode produisant une entropie ralentie artificiellement, telle que PBKDF2, décrite dans PKCS # 5 ...
Oui, veuillez utiliser un algorithme lent à calculer, mais qu'est-ce que "entropie-enduisant"? Mettre un mot de passe d'entropie faible dans un hachage n'augmente pas l'entropie. Cela devrait préserver entropie, mais vous ne pouvez pas améliorer un mot de passe ordures avec un hash, cela ne fonctionne pas comme ça. Un mot de passe faible entré via PBKDF2 est toujours un mot de passe faible.
Il n'y a pas une seule réponse à cette question car il y a trop de variables, mais SHA2 n'est pas encore vraiment fissuré (voir: Lifetimes des fonctions de hachage cryptographique ), donc c'est toujours un bon algorithme à utiliser pour stocker les mots de passe. L'utilisation de salt est bonne car elle empêche les attaques de attaques par dictionnaire ou des tables Rainbow. L'importance d'un sel est qu'il doit être unique pour chaque mot de passe. Vous pouvez utiliser un format tel que [sel 128 bits] [hachage de mot de passe 512 bits] lors du stockage des mots de passe hachés.
Le seul moyen viable d’attaquer est de calculer les hachages pour différentes possibilités de mot de passe et, éventuellement, de trouver le bon en faisant correspondre les hachages.
Pour donner une idée du nombre de hachages qui peuvent être faits en une seconde, je pense que Bitcoin est un exemple décent. Bitcoin utilise SHA256 et pour faire court, plus vous générez de hachages, plus vous obtenez de bitcoins (que vous pouvez échanger contre de l'argent réel) et, en tant que tel, les gens sont motivés à utiliser des GPU à cette fin. Vous pouvez voir dans la vue d'ensemble du matériel qu'une carte graphique moyenne ne coûtant que 150 USD peut calculer plus de 200 millions de hachages/s. Plus votre mot de passe est long et complexe, plus il prendra de temps. En calculant à 200 M/s, il faut environ 300 heures pour essayer toutes les possibilités d’un alphanumérique à 8 caractères (majuscules, nombres inférieurs). Le temps réel sera probablement moins si le mot de passe est quelque chose d’éligible ou un mot anglais courant.
En tant que tel, avec tout ce qui concerne la sécurité, vous devez examiner le contexte. Quelle est la motivation de l'attaquant? Quel est le type d'application? Avoir un hachage avec du sel aléatoire pour chaque donne une assez bonne protection contre les cas où quelque chose comme des milliers de mots de passe sont compromis.
Une chose que vous pouvez faire est également d’ajouter une protection supplémentaire contre la force brute en en ralentissant la procédure de hachage. Comme vous ne hachez qu'une fois les mots de passe et que l'attaquant doit le faire plusieurs fois, cela fonctionne en votre faveur. La manière typique de faire est de prendre une valeur, de la hacher, de prendre la sortie, de la hacher à nouveau et ainsi de suite pour un nombre fixe d'itérations. Vous pouvez essayer quelque chose comme 1 000 ou 10 000 itérations par exemple. Ainsi, l'attaquant trouvera plusieurs fois plus lentement chaque mot de passe.