Combien de temps pour forcer un SHA-512 salé? (le 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 moment de forcer pour quand le mot de passe est un mot du dictionnaire et aussi quand ce n'est pas un mot du dictionnaire.
3 réponses
dans votre cas, briser l'algorithme de hachage est équivalent à trouver 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 un preimage attack ), vous avez juste besoin de trouver une sortie de la fonction de hachage qui est égale au hachage d'un mot de passe valide (donc "collision"). Trouver une collision en utilisant un "birthday attack prend du temps O(2^(n/2)), où n est la longueur de sortie de la fonction de hachage en bit.
SHA-2 a une taille de sortie de 512 bits, donc trouver une collision prendrait du temps O(2^256). Étant donné qu'il n'y a pas d'attaques intelligentes sur l'algorithme lui-même (actuellement aucun n'est connu pour la famille de hachage SHA-2) c'est ce qu'il faut pour casser l'algorithme.
pour se faire une idée de ce que signifie réellement 2^256: actuellement, on pense que le nombre d'atomes dans le (entier!!!) l'univers est d'environ 10 ^ 80, soit environ 2 ^ 266. En supposant une entrée de 32 octets (ce qui est raisonnable pour votre cas - 20 octets sel + 12 octets mot de passe) ma machine prend ~0,22 s (~2^-2s) pour 65536 (=2^16) calculs. Ainsi 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
appeler ces millions d'années est ridicule. Et ça ne va pas beaucoup mieux avec le matériel le plus rapide de la planète calculant des milliers de hachures en parallèle. Aucune technologie humaine ne pourra transformer ce nombre en quelque chose acceptable.
alors oubliez SHA-256. Votre prochaine question portait sur les mots du dictionnaire. Pour récupérer ces mots de passe faibles tables arc-en-ciel ont été utilisés traditionnellement. Une table arc-en-ciel est généralement juste une table de valeurs de hachage précalculées, l'idée est que si vous étiez en mesure de précalculer et stocker chaque hachage possible avec son entrée, alors il vous faudrait O(1) pour chercher un hachage donné et récupérer un préimage valide pour lui. Bien sûr, c'est pas possible dans la pratique car il n'y a pas de périphérique de stockage qui pourrait stocker des quantités énormes de données. Ce dilemme est connu sous le nom de échange Mémoire-temps . Comme vous êtes seulement capable de stocker tant de valeurs les tables arc-en-ciel typiques incluent une certaine forme de hachage avec des fonctions de réduction intermédiaire (ceci est expliqué en détail dans L'article de Wikipedia) pour économiser de l'espace en abandonnant un peu d'économies de temps.
sels étaient une contre-mesure pour faire de telles tables arc-en-ciel sont infaisables. Pour décourager les attaquants de précomputer une table pour un sel spécifique, il est recommandé d'appliquer des valeurs de sel par utilisateur. Cependant, puisque les utilisateurs n'utilisent pas les mots de passe sécurisés, complètement aléatoires, il est encore surprenant comment vous pouvez obtenir le succès si le sel est connu et vous itérez juste sur un grand dictionnaire de mots de passe communs dans un essai simple et le schéma d'erreur. La relation entre le langage naturel et le hasard s'exprime par entropie . Les choix de mots de passe typiques sont généralement de faible entropie, alors que des valeurs complètement aléatoires contiendraient un maximum d'entropie.
la faible entropie des mots de passe typiques rend possible qu'il y ait une chance relativement élevée que l'un de vos utilisateurs utilise un mot de passe à partir d'une base de données relativement petite de mots de passe communs. Si vous les Cherchez sur google, vous finirez par trouver des liens torrent pour ces bases de données de mots de passe, souvent dans la catégorie de taille gigaoctet. Réussir avec une telle l'outil est généralement dans la gamme de quelques minutes à quelques jours, si l'attaquant n'est pas limité en aucune manière.
C'est pourquoi, généralement, le hachage et le salage seul n'est pas suffisant, vous devez installer d'autres mécanismes de sécurité. Vous devriez utiliser une méthode d'entraînement ralentie artificiellement telle que PBKDF2 décrite dans PKCS#5 et vous devriez imposer une période d'attente pour un utilisateur donné avant qu'ils puissent entrer de nouveau leur mot de passe. Un bon programme est de commencer avec 0,5 s et ensuite doubler ce temps pour chaque tentative ratée. Dans la plupart des cas, les utilisateurs ne s'en rendent pas compte et n'échouent pas beaucoup plus souvent que trois fois en moyenne. Mais il ralentira considérablement tout Outsider malveillant essayant d'attaquer votre application.
je veux savoir le temps de la force brute pour quand le mot de passe est un mot du dictionnaire, et aussi lorsqu'il n'est pas un mot du dictionnaire.
mot de passe du dictionnaire
Ballpark figure : il y a environ 1.000.000 de mots anglais, et si un hacker peut calculer environ 10.000 SHA-512 hashes par seconde ( mise à jour: voir commentaire de CodesInChaos, cette estimation est très faible), 1.000.000 / 10 000 = 100 secondes . Il faudrait donc un peu plus d'une minute pour déchiffrer un mot de passe de dictionnaire pour un seul utilisateur. Si l'utilisateur concaténate deux mots du dictionnaire, vous êtes dans le domaine de quelques jours, mais encore très possible si l'attaquant est assez soins. Plus que ça et ça devient 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, puis le nombre de mots de passe possibles de longueur N est 60^n (il y a 60 caractères possibles). Nous allons faire le calcul dans l'autre sens cette fois; nous allons demander: quelle longueur de mot de passe pourrions-nous cracker étant donné une longueur de temps spécifique? il suffit d'utiliser cette formule:
N = Log60(t * 10,000) où t est le temps passé à calculer les hachures en secondes (en supposant à nouveau 10 000 hachures par seconde).
1 minute: 3.2
5 minute: 3.6
30 minutes: 4.1
2 hours: 4.4
3 days: 5.2
donc avec 3 jours on pourrait déchiffrer le mot de passe s'il fait 5 caractères.
tout Cela est très-ball park, mais vous obtenez l'idée. mise à jour: voir le commentaire ci-dessous, il est en fait possible de craquer des mots de passe beaucoup plus long que celui-ci.
que se passe-t-il ici?
clarifions quelques idées fausses:
-
le sel ne fait pas il est plus lent à calculer les hash , cela signifie Juste qu'ils doivent craquer le mot de passe de chaque utilisateur individuellement, et pré-calculé des tables de hash (buzz-word: tables arc-en-ciel ) sont rendus complètement inutiles. Si vous n'avez pas de table de hachage précomputée, et que vous ne cassez qu'un hachage de mot de passe, saler ne fait aucune différence.
-
SHA-512 n'est pas conçu pour être dur pour la force brute . Mieux hachage des algorithmes 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 coups par seconde. Lisez cette excellente réponse à propos du hachage de mot de passe si vous ne l'avez pas déjà fait.
-
mise à jour: Comme écrit dans le commentaire par CodesInChaos, même à haute entropie des mots de passe (autour de 10 caractères) pourrait être bruteforced si vous utilisez le bon matériel pour calculer les Hash SHA-512.
Notes sur la réponse acceptée:
la réponse acceptée à partir de septembre 2014 est incorrecte et dangereusement fausse:
dans votre cas, briser l'algorithme de hachage est équivalent à trouver une collision dans l'algorithme de hachage. Cela signifie que vous n'avez pas besoin de trouver le mot de passe elle-même (ce qui serait une attaque de préimage)... 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.
de L'attaque d'anniversaire est complètement hors de propos à la fissuration d'une donnée de hachage. Et c'est en fait un parfait exemple d'attaque de préimage . Cette formule et les prochains paragraphes résultat dans dangereusement élevé et complètement dénuée de sens valeurs pour un temps d'attaque. Comme démontré ci-dessus il est parfaitement possible de craquer les mots de passe salés du dictionnaire en quelques minutes .
la faible entropie des mots de passe typiques rend possible qu'il y ait une chance relativement élevée que l'un de vos utilisateurs utilise un mot de passe à partir d'une base de données relativement petite de mots de passe communs...
C'est pourquoi, généralement, le hachage et le salage seul n'est pas suffisant, vous devez installer d'autres mécanismes de sécurité. Vous devez utiliser une méthode d'entraînement ralentie artificiellement telle que PBKDF2 décrite dans PKCS#5...
Oui, veuillez utiliser un algorithme qui est lent à calculer, mais qu'est-ce que "l'entropie-enducing"? Mettre un mot de passe d'entropie faible à travers un hachage n'augmente pas l'entropie. Il devrait préserver entropie, mais vous ne pouvez pas faire un mot de passe poubelle mieux avec un hachage, il ne fonctionne pas comme cela. un faible mot de passe passé par PBKDF2 est encore 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 of cryptographic hash functions ) de sorte qu'il est encore un bon algorithme à utiliser pour stocker les mots de passe. L'utilisation du sel est bonne parce qu'il empêche l'attaque de dictionnaires attaques ou tables arc-en-ciel. L'Importance d'un sel, c'est qu'il doit être unique pour chaque mot de passe. Vous pouvez utiliser un format comme [128 bits salt] [512-bit password hash] lors du stockage des mots de passe hash.
la seule façon viable d'attaquer est de calculer les hachures pour différentes possibilités de mot de passe et éventuellement trouver la bonne en faisant correspondre les hachures.
pour donner une idée du nombre de hashs qui peuvent être faits en une seconde, je pense que Bitcoin est un bon exemple. Bitcoin utilise SHA256 et pour le couper court, plus vous générez de hachures, plus vous bitcoins obtenir (que vous pouvez échanger contre de l'argent réel) et comme tels les gens sont motivés à utiliser des GPUs à cette fin. Vous pouvez voir dans l'aperçu matériel qu'une carte graphique moyenne qui ne coûte que 150 $peut calculer plus de 200 millions de hashs/s. Plus votre mot de passe est long et complexe, plus il vous faudra de temps. Calculer à 200M / s, pour essayer toutes les possibilités pour un 8 caractères alphanumériques (capital, inférieur, numéros) prendra environ 300 heures. Le temps réel sera plus probablement moins si le mot de passe est quelque chose d'admissible ou un mot anglais commun.
en tant que tel avec n'importe quoi de sécurité que vous devez regarder dans le contexte. Quelle est la motivation de l'agresseur? Quel est le type de demande? 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 ajouter la protection de la force brute supplémentaire par ralentissement dans la procédure de hachage. Comme vous ne hachez les mots de passe qu'une fois, 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, la hacher, prendre la sortie, la hacher de nouveau et ainsi de suite pour une quantité 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 l'attaquant de trouver chaque mot de passe.