Combien de temps pour forcer brutalement un hash SHA-512 salé? (sel fourni)

Voici un algorithme en Java:

public Ssortingng getHash(Ssortingng password, Ssortingng salt) throws Exception { Ssortingng input = password + salt; MessageDigest md = MessageDigest.getInstance(SHA-512); byte[] out = md.digest(input.getBytes()); return HexEncoder.toHex(out); } 

Supposez que le sel est connu. Je veux connaître le temps de force brute pour quand le mot de passe est un mot de dictionnaire et aussi quand ce n’est pas un mot de 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 (qui serait une attaque de pré-image ), il vous suffit de trouver une sortie de la fonction de hachage égale au hachage d’un mot de passe valide (donc “collision”). Trouver une collision en utilisant une attaque d’anniversaire prend du temps O (2 ^ (n / 2)), où n est la longueur de sortie de la fonction de hachage en bits.

SHA-2 a une taille de sortie de 512 bits, donc trouver une collision prend du temps O (2 ^ 256). Étant donné qu’il n’ya pas d’attaques astucieuses sur l’algorithme lui-même (aucun n’est actuellement connu pour la famille de hachage SHA-2), c’est ce qu’il faut pour casser l’algorithme.

Pour avoir une idée de ce que signifie 2 ^ 256: actuellement, on pense que le nombre d’atomes dans l’univers (entier !!!) est d’environ 10 ^ 80, ce qui correspond à peu près à 2 ^ 266. En supposant une entrée de 32 octets (ce qui est raisonnable pour votre cas – 20 octets de sel + 12 octets de mot de passe), ma machine prend ~ 0,22s (~ 2 ^ -2s) pour 65536 (= 2 ^ 16) calculs. Donc, deux cent vingt-cinq calculs seraient effectués en vingt-deux cent vingt-deux calculs

 2^240 * 2^-2 = 2^238 ~ 10^72s ~ 3,17 * 10^64 years 

Même appeler ces 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 pourra transformer ce nombre en quelque chose d’acceptable.

Alors oubliez le forçage brutal SHA-256 ici. Votre prochaine question portait sur les mots du dictionnaire. Pour retrouver de tels mots de passe faibles, les tables arc-en-ciel étaient traditionnellement utilisées. Une table arc-en-ciel n’est généralement qu’une table de valeurs de hachage précalculées. L’idée est que si vous pouviez précalculer et stocker tous les hachages possibles avec ses entrées, il vous faudrait O (1) pour rechercher un hachage pré-image valide pour cela. Bien sûr, cela n’est pas possible dans la pratique car il n’existe aucun périphérique de stockage capable de stocker des quantités aussi importantes de données. Ce dilemme est connu sous le nom de compromis mémoire-temps . Comme vous ne pouvez stocker que beaucoup de valeurs, les tables arc-en-ciel incluent une forme de chaînage de hachage avec des fonctions de réduction intermédiaires (cela est expliqué en détail dans l’article de Wikipedia) pour économiser de l’espace.

Les sels étaient une contre-mesure pour rendre de telles tables arc-en-ciel irréalisables. Pour décourager les pirates de pré-calculer une table pour un sel spécifique, il est recommandé d’appliquer des valeurs de sel par utilisateur. Cependant, comme les utilisateurs n’utilisent pas de mots de passe sécurisés et complètement aléatoires, il est toujours surprenant de savoir si vous pouvez obtenir un bon résultat en parcourant un grand dictionnaire de mots de passe courants dans un système de test et d’erreur simple. La relation entre langage naturel et caractère aléatoire est exprimée par l’ entropie . Les choix de mot de passe typiques sont généralement de faible entropie, alors que les valeurs complètement aléatoires contiendraient un maximum d’entropie.

La faible entropie des mots de passe typiques rend possible la probabilité relativement élevée qu’un de vos utilisateurs utilise un mot de passe à partir d’une firebase database relativement petite de mots de passe courants. Si vous utilisez google pour eux, vous finirez par trouver des liens torrent pour de telles bases de données de mots de passe, souvent dans la catégorie de taille gigaoctet. La réussite d’un tel outil se situe généralement entre quelques minutes et quelques jours si l’attaquant n’est soumis à aucune ressortingction.

C’est pourquoi le hachage et le salage ne suffisent généralement pas, vous devez également installer d’autres mécanismes de sécurité. Vous devez utiliser une méthode de création d’entropie ralentie artificiellement telle que PBKDF2 décrite dans PKCS # 5 et vous devez appliquer une période d’attente pour un utilisateur donné avant de pouvoir réessayer d’entrer son mot de passe. Un bon plan est de commencer avec 0,5s puis de doubler ce temps pour chaque tentative ratée. Dans la plupart des cas, les utilisateurs ne le remarquent pas et n’échouent pas beaucoup plus souvent que trois fois en moyenne. Mais cela ralentira considérablement toute personne malveillante tentant d’attaquer votre application.

Je veux connaître le temps de force brute pour quand le mot de passe est un mot de dictionnaire et aussi quand ce n’est pas un mot de dictionnaire.

Mot de passe du dictionnaire

Ballpark : il y a environ 1 000 000 de mots anglais, et si un hacker peut calculer environ 10 000 SHA-512 par seconde ( update: voir commentaire de CodesInChaos, cette estimation est très faible), 1 000 000/10 000 = 100 secondes . Il ne faudrait donc qu’une minute pour déchiffrer un mot de passe de dictionnaire à un seul mot pour un seul utilisateur. Si l’utilisateur concatène deux mots de dictionnaire, vous êtes dans la zone de quelques jours, mais toujours très possible si l’attaquant est suffisamment concerné. Plus que cela et ça commence à devenir difficile.

Mot de passe aléatoire

Si le mot de passe est une séquence vraiment aléatoire de caractères alphanumériques, majuscules et minuscules, le nombre de mots de passe possibles de longueur N est 60 ^ N (il y a 60 caractères possibles). Nous ferons le calcul dans l’autre sens cette fois; nous demanderons: quelle longueur de mot de passe pourrions-nous déchiffrer en fonction d’une durée spécifique? Utilisez simplement cette formule:

N = Log60(t * 10,000) où t est le temps passé à calculer les hachages en secondes (en supposant à nouveau que 10 000 hachages par seconde).

 1 minute: 3.2 5 minute: 3.6 30 minutes: 4.1 2 hours: 4.4 3 days: 5.2 

Donc, avec un délai de 3 jours, nous pourrions déchiffrer le mot de passe s’il contient 5 caractères.

Ceci est tout à fait ballon, mais vous avez l’idée. Mise à jour: voir commentaire ci-dessous, il est en fait possible de craquer des mots de passe beaucoup plus longs que cela.

Que se passe t-il ici?

Éclaircissons quelques idées fausses:

  • Le sel ne rend pas plus lent le calcul des hachages , cela signifie simplement qu’ils doivent déchiffrer le mot de passe de chaque utilisateur individuellement, et les tables de hachage pré-calculées (buzz-word: rainbow tables ) sont complètement inutiles. Si vous ne disposez pas d’une table de hachage précalculée et que vous ne craquez qu’un mot de passe, le salage ne fait aucune différence.

  • SHA-512 n’est pas conçu pour être difficile à forcer . 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 peut uniquement calculer 10 à 20 hachages par seconde. Lisez cette excellente réponse sur le hachage de 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) peuvent être renforcés si vous utilisez le bon matériel 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 erronée:

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 (qui serait une attaque de pré-image) … Trouver une collision en utilisant une attaque d’anniversaire prend du temps O (2 ^ n / 2), n étant la longueur de sortie du hachage Fonctionne en bits.

L’attaque d’anniversaire n’a rien à voir avec le craquage d’un hash donné. Et c’est en fait un exemple parfait d’attaque pré-image . Cette formule et les deux paragraphes suivants entraînent des valeurs dangereusement élevées et complètement dépourvues 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 types permet à un de vos utilisateurs d’utiliser un mot de passe à partir d’une firebase database relativement restreinte de mots de passe courants …

C’est pourquoi le hachage et le salage ne suffisent généralement pas, vous devez également installer d’autres mécanismes de sécurité. Vous devez utiliser une méthode de création d’entropie ralentie artificiellement telle que PBKDF2 décrite dans PKCS # 5 …

Oui, veuillez utiliser un algorithme lent à calculer, mais qu’est-ce que “entropy-enducing”? Mettre un mot de passe à faible entropie à travers un hachage n’augmente pas l’entropie. Cela devrait préserver l’ entropie, mais vous ne pouvez pas améliorer le mot de passe avec un hash, cela ne fonctionne pas comme ça. Un mot de passe faible transmis via PBKDF2 rest 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: Durée de vie des fonctions de hachage cryptographiques ), il rest donc un bon algorithme pour stocker les mots de passe. Le sel est bon car il empêche les attaques des dictionnaires ou des tables arc-en-ciel. L’importance d’un sel est qu’il doit être unique pour chaque mot de passe. Vous pouvez utiliser un format tel que [sel de 128 bits] [hachage de mot de passe de 512 bits] lors du stockage des mots de passe hachés.

Le seul moyen viable d’attaquer consiste à calculer les hachages pour différentes possibilités de mot de passe et à trouver le bon en faisant correspondre les hachages.

Pour donner une idée du nombre de hachages pouvant être effectués en une seconde, je pense que Bitcoin est un bon exemple. Bitcoin utilise SHA256 et pour réduire le temps, plus vous générez de hachages, plus vous obtenez de bitcoins (que vous pouvez échanger contre de l’argent réel) et, par conséquent, les gens sont motivés pour utiliser des GPU à cette fin. Vous pouvez voir dans l’aperçu du matériel qu’une carte graphique moyenne qui ne coûte que 150 $ peut calculer plus de 200 millions de hachages / s. Plus votre mot de passe est long et complexe, plus cela prendra du temps. Calculer à 200M / s, pour essayer toutes les possibilités pour un caractère alphanumérique de 8 caractères (majuscules, chiffres inférieurs), prendra environ 300 heures. Le temps réel sera probablement moindre si le mot de passe est éligible ou un mot anglais commun.

En tant que tel avec tout ce que la sécurité vous devez regarder dans son contexte. Quelle est la motivation de l’attaquant? Quel est le type d’application? Avoir un hachage avec du sel aléatoire pour chacun 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’append une protection supplémentaire de la force brute en ralentissant la procédure de hachage. Comme vous ne hachez qu’une seule fois les mots de passe et que l’attaquant doit le faire plusieurs fois, cela fonctionne en votre faveur. La façon 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. Cela le rendra plusieurs fois plus lent pour que l’attaquant trouve chaque mot de passe.