Pourquoi les sels rendent-ils les attaques par dictionnaire «impossibles»?

85

Mise à jour: Veuillez noter que je ne demande pas ce qu'est un sel, ce qu'est une table arc-en-ciel, ce qu'est une attaque par dictionnaire ou quel est le but d'un sel. Je demande: si vous connaissez le sel et le hachage des utilisateurs, n'est-il pas assez facile de calculer leur mot de passe?

Je comprends le processus et je le mets moi-même en œuvre dans certains de mes projets.

s =  random salt
storedPassword = sha1(password + s)

Dans la base de données que vous stockez:

username | hashed_password | salt

Chaque implémentation de salage que j'ai vue ajoute le sel soit à la fin du mot de passe, soit au début:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

Par conséquent, une attaque par dictionnaire d'un hacker qui vaut son sel (ha ha) exécuterait simplement chaque mot-clé contre les sels stockés dans les combinaisons courantes énumérées ci-dessus.

Sûrement, la mise en œuvre décrite ci-dessus ajoute simplement une autre étape pour le pirate informatique, sans réellement résoudre le problème sous-jacent? Quelles alternatives existe-t-il pour contourner ce problème, ou est-ce que je comprends mal le problème?

La seule chose que je peux penser à faire est d'avoir un algorithme de mélange secret qui associe le sel et le mot de passe dans un motif aléatoire, ou ajoute d'autres champs utilisateur au processus de hachage, ce qui signifie que le pirate devrait avoir accès à la base de données ET au code pour lacer pour qu’une attaque par dictionnaire se révèle fructueuse. (Mise à jour, comme indiqué dans les commentaires, il est préférable de supposer que le pirate a accès à toutes vos informations, donc ce n'est probablement pas le meilleur).

Permettez-moi de donner un exemple de la façon dont je propose qu'un pirate pirate une base de données utilisateur avec une liste de mots de passe et de hachages:

Données de notre base de données piratée:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

Dictionnaire de mots de passe commun:

   Common Password
   --------------
   letmein
   12345
   ...

Pour chaque enregistrement utilisateur, bouclez les mots de passe communs et hachez-les:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

J'espère que cela illustre beaucoup mieux mon propos.

Compte tenu de 10 000 mots de passe courants et de 10 000 enregistrements d'utilisateurs, nous aurions besoin de calculer 100 000 000 de hachages pour découvrir autant de mots de passe d'utilisateurs que possible. Cela peut prendre quelques heures, mais ce n'est pas vraiment un problème.

Mise à jour sur la théorie du craquage

Nous supposerons que nous sommes un hébergeur corrompu, qui a accès à une base de données de hachages et de sels SHA1, avec votre algorithme pour les mélanger. La base de données contient 10 000 enregistrements d'utilisateurs.

Ce site prétend pouvoir calculer 2 300 000 000 de hachages SHA1 par seconde en utilisant le GPU. (Dans la situation du monde réel, ce sera probablement plus lent, mais pour l'instant, nous utiliserons ce chiffre cité).

(((95 ^ 4) / 2300000000) / 2) * 10000 = 177 secondes

Étant donné une gamme complète de 95 caractères ASCII imprimables, avec une longueur maximale de 4 caractères, divisée par le taux de calcul (variable), divisé par 2 (en supposant que le temps moyen pour découvrir le mot de passe nécessitera en moyenne 50% de permutations) pour 10000 utilisateurs, il faudrait 177 secondes pour déterminer tous les mots de passe des utilisateurs dont la longueur est <= 4.

Ajustez un peu pour le réalisme.

(((36 ^ 7) / 1000000000) / 2) * 10000 = 2 jours

En supposant la non-sensibilité à la casse, avec une longueur de mot de passe <= 7, uniquement des caractères alphanumériques, il faudrait 4 jours pour résoudre 10000 enregistrements d'utilisateurs, et j'ai réduit de moitié la vitesse de l'algorithme pour refléter les frais généraux et les circonstances non idéales.

Il est important de reconnaître qu'il s'agit d'une attaque par force brute linéaire, tous les calculs sont indépendants les uns des autres, c'est donc une tâche parfaite pour plusieurs systèmes à résoudre. (IE facile à configurer 2 ordinateurs exécutant une attaque de différentes extrémités qui réduiraient la moitié du temps d'exécution).

Étant donné le cas du hachage récursif d'un mot de passe 1000 fois pour rendre cette tâche plus coûteuse en calcul:

(((36 ^ 7) / 1 000 000 000) / 2) * 1000 secondes = 10,8839117 heures

Cela représente une longueur maximale de 7 caractères alphanumériques, à une vitesse d'exécution inférieure à la moitié de la valeur citée pour un utilisateur .

Le hachage récursif 1 000 fois bloque efficacement une attaque globale, mais les attaques ciblées sur les données des utilisateurs restent vulnérables.

security  hash  salt  dictionary-attack 
— Tom Gullen
source
12
L'intérêt du salage est de vous empêcher de pouvoir regarder le mot de passe haché et de voir que plusieurs utilisateurs ont le même hachage (et donc le même mot de passe). Sans salage, vous pouvez simplement utiliser l'algorithme de hachage et générer tous les hachages possibles, puis effectuer une recherche brute pour ce hachage. Comme l'algorithme ne change jamais, il est prévisible pour les attaquants, le salage le rend encore plus difficile.
— BeRecursive
25
Parce que les craquelins sont comme des limaces et que le sel assèche les muqueuses de leur peau et les tue.
— TED
6
@TED: J'aime plutôt les craquelins salés. Limaces salées, pas tellement.
— FrustratedWithFormsDesigner
3
@Tom - dans votre exemple d'attaque. S'il n'y a pas de sel, alors l'attaquant peut faire "pour chaque mot de passe commun, hacher le mot de passe. Cela correspond-il à un ou plusieurs utilisateurs? Oui, j'ai leur mot de passe" - l'attaquant est capable d'attaquer tous les mots de passe "en parallèle" , sans frais supplémentaires.
— Damien_The_Unbeliever
3
@Tom Gullen - vous n'avez que la moitié de l'image. Sans sel, un attaquant n'utiliserait pas la méthode que vous démontrez dans "Update 2". Il ferait simplement une recherche dans une table et obtiendrait le mot de passe en temps O (1) ou O (log n) (n étant le nombre de mots de passe candidats). Le sel est ce qui empêche cela et le force à utiliser l'approche O (n) que vous démontrez. Une autre technique (renforcement des clés) peut faire en sorte que chaque tentative dans votre boucle dure une seconde complète, ce qui signifie qu'il faudra 3 ans pour effectuer ces tests ... et avec seulement 10k mots de passe, vous risquez de ne craquer aucun mot de passe. temps.
— erickson

Réponses:

31

Oui, vous n'avez besoin que de 3 jours pour sha1 (sel | mot de passe). C'est pourquoi de bons algorithmes de stockage de mots de passe utilisent un hachage de 1000 itérations: il vous faudra 8 ans.

— flamber
source
3
+1, la réponse la plus concise et la plus précise jusqu'à présent, je n'étais pas au courant que c'était une option.
— Tom Gullen
Apparemment, vous n'avez jamais effectué de test de hachage sur votre système. Vous pouvez effectuer BEAUCOUP DES MILLIONS de calculs sha1 par seconde. Un millier de coups n'a aucun sens pour un attaquant. Aussi -1 parce que sha1 est une fonction de hachage cassée.
— Tour du
Apparemment, j'utilise des noms et des numéros de question. Si vous avez déjà entendu parler de sujet et de clarté ... oh, c'est Rook. Ça ne fait rien.
— blaze le
1
@Rook, 1000 rounds signifie qu'il faudra 1000 fois plus de temps à la force brute. Cela me semble être une bonne fonctionnalité.
— Tom Gullen
si un attaquant peut deviner un mot de passe, est-ce la même chose pour la connexion (ou quelque chose m'a échappé? lol)
— khaled_webdev
62

Cela n'arrête pas les attaques par dictionnaire.

Cela empêche quelqu'un qui parvient à obtenir une copie de votre fichier de mot de passe d'utiliser une table arc-en-ciel en pour déterminer quels sont les mots de passe à partir des hachages.

Finalement, cela peut être forcé brutalement. La réponse à cette partie est de forcer vos utilisateurs à ne pas utiliser les mots du dictionnaire comme mots de passe (exigences minimales d'au moins un chiffre ou caractère spécial, par exemple).

Mise à jour :

J'aurais dû le mentionner plus tôt, mais certains (la plupart?) Systèmes de mot de passe utilisent un sel différent pour chaque mot de passe, probablement stocké avec le mot de passe lui-même. Cela rend inutile une seule table arc-en-ciel. C'est ainsi que la crypte UNIX bibliothèque de , et les systèmes d'exploitation modernes de type UNIX ont étendu cette bibliothèque avec de nouveaux algorithmes de hachage.

Je sais pertinemment que la prise en charge de SHA-256 et SHA-512 a été ajoutée dans les nouvelles versions de GNU crypt.

— Powerlord
source
17
+1 Salt empêche les listes de hachages précalculées (tables arc-en-ciel) d'être utiles. L'attaquant doit tout recommencer.
— Ian Boyd
2
En PHP, vous pouvez utiliser les bibliothèques mcrypt ou bcrypt pour un meilleur cryptage que md5 ou sha1. Si vous êtes coincé avec md5 ou sha1, vous devriez «étirer», où vous hachez le mot de passe des milliers de fois avant d'arriver à tout ce qui est stocké dans la base de données. Cela garde l'entropie la même, mais augmente le temps de calcul du hachage.
— Malfist
2
@Tom Gullen, quels articles lisez-vous? Des experts autoproclamés ou des articles évalués par des pairs dans une revue scientifique?
— Malfist
7
Et c'est votre développeur Joe moyen qui fait ces articles de blog / d'aide sur la façon d'écrire un système «sécurisé». La sécurité n'est pas quelque chose que vous pouvez appréhender sur le côté, elle nécessite des connaissances approfondies. Est-ce injuste? Probablement. Est-ce sûr? À un degré. Il y a des raisons pour lesquelles il y a des experts en sécurité. Mais là encore, tout ne doit pas être aussi sûr que Fort Knox. La meilleure politique ici est d'utiliser un système prédéfini conçu par ces experts et de le modifier pour répondre à vos besoins.
— Malfist du
3
@Michael: Avec un sel plus long, vous devez précalculer toutes les valeurs de sel possibles, pour qu'il apparaisse dans la table arc-en-ciel. Le fait est que vous ne conservez pas le même sel pour tous les mots de passe, vous le choisissez au hasard pour chaque mot de passe et vous le stockez dans la base de données à côté du mot de passe haché stocké. Ainsi, un pirate informatique aurait besoin d'une entrée dans la table arc-en-ciel pour chaque sel de grande valeur possible, ce qui rendrait la table trop grande pour être faisable, ce qui est le point.
— Colin DeClue
31

Pour être plus précis, une attaque par dictionnaire , c'est-à-dire une attaque où tous les mots d'une liste exhaustive sont essayés, n'est pas "impossible", mais elle devient irréalisable : chaque bit de sel double la quantité de stockage et de calcul nécessaires .

Ceci est différent des attaques de dictionnaire pré-calculées comme les attaques impliquant des tables arc-en-ciel où peu importe que le sel soit secret ou non.

Exemple: Avec un salt 64 bits (soit 8 octets), vous devez vérifier 2 64 combinaisons de mots de passe supplémentaires dans votre attaque par dictionnaire. Avec un dictionnaire de 200 000 mots, vous devrez faire

200 000 * 2 64 = 3,69 * 10 24

tests dans le pire des cas - au lieu de 200 000 tests sans sel.

Un autre avantage de l'utilisation de salt est qu'un attaquant ne peut pas pré-calculer les hachages de mot de passe à partir de son dictionnaire. Cela prendrait simplement trop de temps et / ou d'espace.

Mise à jour

Votre mise à jour suppose qu'un attaquant connaît déjà le sel (ou l'a volé). C'est bien sûr une situation différente. Il n'est toujours pas possible pour l'attaquant d'utiliser une table arc-en-ciel précalculée. Ce qui compte beaucoup ici, c'est la vitesse de la fonction de hachage. Pour rendre une attaque impraticable, la fonction de hachage doit être lente. MD5 ou SHA ne sont pas de bons candidats ici car ils sont conçus pour être rapides, de meilleurs candidats pour les algorithmes de hachage sont Blowfish ou certaines de ses variantes.

Mise à jour 2

Une bonne lecture sur la question de la sécurisation de vos hachages de mots de passe en général (allant bien au-delà de la question d'origine mais toujours intéressante):

Assez avec les tableaux arc-en-ciel: ce que vous devez savoir sur les schémas de mot de passe sécurisé

Corollaire de l'article: Utilisez des hachages salés créés avec bcrypt (basé sur Blowfish) ou Eksblowfish qui vous permet d'utiliser un temps de configuration configurable pour ralentir le hachage.

— Dirk Vollmar
source
4
@Tom Gullen - même avec des politiques de mot de passe suffisamment solides, un dictionnaire de centaines de millions ou de quelques milliards de candidats est susceptible d'obtenir des résultats, car tous les mots de passe ne sont pas également probables (car les gens utilisent des mnémoniques, plutôt que des RNG, pour les choisir) . Un dictionnaire de cette taille est précalculable sur les systèmes de produits de base si le sel n'est pas utilisé. Si le sel est utilisé, l'attaquant doit recalculer les hachages à chaque fois, et si suffisamment d'itérations du hachage sont effectuées, le taux d'attaque de l'attaquant peut être ralenti à quelques tentatives par seconde.
— erickson
3
-1 de ma part: être tenu secret n'est absolument pas le but des sels. Vous en avez besoin de toute façon accessibles pour vérifier les mots de passe, de sorte que toute tentative de les garder secrets est susceptible de rendre le système plus vulnérable par une complexité accrue plutôt que de réussir.
— Michael Borgwardt
2
@ 0xA3: encore une fois: être inconnu d'un attaquant n'est pas le but d'un sel . Votre machine doit y accéder d'une manière ou d'une autre, de sorte qu'un attaquant qui s'introduit dans la machine peut également l'obtenir. Tout scénario dans lequel l'attaquant ne connaît pas le sel est un hareng rouge.
— Michael Borgwardt
1
Je pense qu'il vaut la peine de mentionner que l'article lié décrit mal les tables arc-en-ciel. Ce qu'il décrit est une simple attache de dictionnaire. Les tables arc-en-ciel sont vraiment très différentes (et un peu plus complexes). Il y a une explication assez décente de la façon dont les tables arc -en - vraiment travailler à: kestas.kuliukas.com/RainbowTables
— Coffin Jerry
3
-1 pour "Bien sûr, le sel doit être gardé secret". Si un attaquant a accès à vos hachages de mot de passe, il aura également vos sels - ce dont vous avez besoin, ce sont des sels par utilisateur , pas la sécurité par l'obscurité d'un sel «caché».
— snemarch
17

Un dictionnaire est une structure où les valeurs sont indexées par des clés. Dans le cas d'une attaque par dictionnaire pré-calculée, chaque clé est un hachage, et la valeur correspondante est un mot de passe qui entraîne le hachage. Avec un dictionnaire pré-calculé en main, un attaquant peut «instantanément» rechercher un mot de passe qui produira le hachage nécessaire pour se connecter.

Avec le sel, l'espace requis pour stocker le dictionnaire augmente rapidement… si rapidement que tenter de précalculer un dictionnaire de mots de passe devient vite inutile.

Les meilleurs sels sont choisis au hasard dans un générateur de nombres aléatoires cryptographiques. Huit octets est une taille pratique, et plus de 16 octets ne sert à rien.

Le sel fait bien plus que simplement «rendre le travail d'un agresseur plus irritant». Il élimine toute une classe d'attaque: l'utilisation de dictionnaires précalculés.

Un autre élément est nécessaire pour sécuriser complètement les mots de passe, c'est le «renforcement des clés». Un tour de SHA-1 n'est pas assez bon: un algorithme de hachage de mot de passe sûr devrait être très lent en calcul.

De nombreuses personnes utilisent PBKDF2, une fonction de dérivation de clé, qui renvoie les résultats à la fonction de hachage des milliers de fois. L'algorithme "bcrypt" est similaire, utilisant une dérivation itérative de clé qui est lente.

Lorsque l'opération de hachage est très lente, une table précalculée devient de plus en plus souhaitable pour un attaquant. Mais le sel approprié va à l'encontre de cette approche.

commentaires

Voici les commentaires que j'ai faits sur la question.

Sans sel, un attaquant n'utiliserait pas la méthode démontrée dans "Update 2". Il ferait simplement une recherche dans une table pré-calculée et obtiendrait le mot de passe en temps O (1) ou O (log n) (n étant le nombre de mots de passe candidats). Le sel est ce qui empêche cela et l'oblige à utiliser l'approche O (n) montrée dans "Update 2".

Une fois réduit à une attaque O (n), nous devons considérer le temps que prend chaque tentative. Le renforcement des clés peut faire en sorte que chaque tentative dans la boucle dure une seconde complète, ce qui signifie que le temps nécessaire pour tester 10 000 mots de passe sur 10 000 utilisateurs passera de 3 jours à 3 ans. … et avec seulement 10 000 mots de passe, vous risquez d'en casser zéro. mots de passe à cette époque.

Vous devez considérer qu'un attaquant va utiliser les outils les plus rapides qu'il peut, pas PHP, donc des milliers d'itérations, plutôt que 100, seraient un bon paramètre pour le renforcement des clés. Le calcul du hachage d'un seul mot de passe devrait prendre une grande fraction de seconde.

Le renforcement de clé fait partie des algorithmes standard de dérivation de clé PBKDF1 et PBKDF2, de PKCS # 5, qui font d'excellents algorithmes d'obfuscation de mot de passe (la «clé dérivée» est le «hachage»).

De nombreux utilisateurs de StackOverflow se réfèrent à cet article car il s'agissait d'une réponse à l'article de Jeff Atwood sur les dangers des tables arc-en-ciel. Ce n'est pas mon article préféré, mais il aborde ces concepts plus en détail.

Bien sûr, vous supposez que l'attaquant a tout: sel, hachage, nom d'utilisateur. Supposons que l'attaquant est un employé corrompu de la société d'hébergement qui a vidé la table des utilisateurs sur votre site de fans myprettypony.com. Il essaie de récupérer ces mots de passe parce qu'il va se retourner et voir si vos fans de poney ont utilisé le même mot de passe sur leurs comptes citibank.com.

Avec un schéma de mot de passe bien conçu, il sera impossible pour ce type de récupérer des mots de passe.

— Erickson
source
1
Je pense que par "attaque par dictionnaire", Tom fait référence à essayer des mots de passe faibles connus (c'est-à-dire tout droit sortis d'un dictionnaire de langage humain), et non des tables de hachage en clair précalculées - c'est aussi ce à quoi je pense pour la première fois quand je lis "dictionnaire" dans ce contexte.
— Michael Borgwardt
@Michael Borgwardt: Je suis d'accord, @erickson fait référence à des attaques par dictionnaire pré-calculées.
— Dirk Vollmar
1
Salt arrête les attaques de dictionnaire pré-calculées. Le renforcement des clés arrête les attaques par dictionnaire. Les deux doivent être utilisés ensemble pour une authentification par mot de passe sécurisé.
— erickson
Je veux dire des tables anglaises simples oui. La question vise à résoudre le problème de savoir comment empêcher un pirate de travailler sur toutes les combinaisons possibles de hachages pour chaque compte utilisateur
— Tom Gullen
7

L'intérêt du salage est d'éviter l'amortissement de l'effort de l'attaquant.

Sans sel, une seule table d'entrées de mot de passe de hachage précalculées (par exemple MD5 de toutes les chaînes alphanumériques de 5 caractères, facile à trouver en ligne) peut être utilisée sur chaque utilisateur de chaque base de données dans le monde.

Avec un sel spécifique au site, l'attaquant doit calculer lui-même la table et peut ensuite l'utiliser sur tous les utilisateurs du site.

Avec un sel par utilisateur, l'attaquant doit déployer cet effort pour chaque utilisateur séparément.

Bien sûr, cela ne fait pas grand-chose pour protéger les mots de passe vraiment faibles tout droit sortis d'un dictionnaire, mais cela protège les mots de passe raisonnablement forts contre cet amortissement.

— Michael Borgwardt
source
1
Réponse courte et précise - il vaut la peine d'ajouter que sans sel ou avec sel à l'échelle du site, vous pouvez facilement repérer les utilisateurs avec le même mot de passe, et n'aura besoin que d'un seul de force brute. Avec les sels par utilisateur, vous ne pouvez pas faire cela.
— snemarch
6

De plus - un autre point important - l'utilisation d'un sel spécifique à l'UTILISATEUR empêche la détection de deux utilisateurs avec le MÊME mot de passe - leurs hachages correspondent. C'est pourquoi le hachage est souvent un hachage (sel + nom d'utilisateur + mot de passe)

Si vous essayez de garder le hachage secret, l'attaquant ne peut pas non plus vérifier les hachages.

Edit- vient de remarquer que le point principal a été fait dans un commentaire ci-dessus.

— Dominik Weber
source
1
Vous devez modifier pour spécifier le sel par utilisateur; les sites utilisant un sel à l'échelle du site vous permettront toujours de détecter des mots de passe identiques.
— snemarch
@snemarch - Oui, merci beaucoup pour cette distinction importante!
— Dominik Weber
5

Les sels sont mis en œuvre pour empêcher les attaques de table arc-en-ciel. Une table arc-en-ciel est une liste de hachages pré-calculés, ce qui rend la traduction d'un hachage en sa phrase beaucoup plus simple. Vous devez comprendre que le salage n'est pas efficace en tant que prévention moderne pour déchiffrer un mot de passe à moins que nous ayons un algorithme de hachage moderne.

Alors disons que nous travaillons avec SHA1, profitons des récents exploits découverts avec cet algo, et disons que nous avons un ordinateur fonctionnant à 1000000 hachages / seconde, il faudrait 5,3 millions de millions d'années pour trouver une collision , alors oui php peut travailler 300 par seconde, gros woop, n'a pas vraiment d'importance. La raison pour laquelle nous salons est que si quelqu'un a pris la peine de générer toutes les expressions courantes du dictionnaire, (2 ^ 160 personnes, bienvenue dans les exploits de l'ère 2007).

Voici donc une base de données réelle, avec 2 utilisateurs que j'utilise à des fins de test et d'administration.

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

En fait, le schéma de salage est votre sha1 (heure d'enregistrement + nom d'utilisateur). Allez-y, dites-moi mon mot de passe, ce sont de vrais mots de passe en production. Vous pouvez même vous asseoir là et hacher une liste de mots en php. Devenir fou.

Je ne suis pas fou, je sais juste que c'est sûr. Pour le plaisir, le mot de passe du test est test. sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

Vous auriez besoin de générer une table arc-en-ciel entière avec 27662aee8eee1cb5ab4917b09bdba31d091ab732pour seul cet utilisateur. Cela signifie que je peux réellement permettre que mes mots de passe ne soient pas tous compromis par une seule table arc-en-ciel, le hacker doit générer une table arc-en-ciel entière pour 27662aee8eee1cb5ab4917b09bdba31d091ab732 pour le test, et encore f3f7735311217529f2e020468004a2af5b3de7. Pensez aux 5,3 millions de millions d'années pour tous les hachages. Pensez à la taille du stockage des 2 ^ 80 hachages (c'est bien plus de 20 yottaoctets ), cela n'arrivera pas.

Ne confondez pas le salage comme un moyen de créer un hachage que vous ne pouvez jamais décoder, c'est un moyen d'empêcher une table arc-en-ciel de traduire tous vos mots de passe utilisateur. C'est impossible à ce niveau de technologie.

— Incognito
source
Je comprends ce qu'est une table arc-en-ciel, mais vous manquez le point de ma question. Si vous m'avez fourni votre algorithme de salage, un mot de passe haché et le sel, alors oui, je pourrais probablement vous dire quel était votre mot de passe en quelques minutes.
— Tom Gullen
Agis plutôt que de parler?
— Incognito
Bien sûr, mais vous venez de me dire quel est le mot de passe dans votre exemple, donnez-moi un sel, un mot de passe haché et comment vous combinez sel + mot de passe (non récursif) et tant que le mot de passe <= 5 caractères alphanumériques minuscules (pas d'espace / caractères spéciaux) Je vous ferai savoir ce que c'est dans cette boîte. Si vous voulez que je mette de l'argent dessus comme vous le suggérez, faites-le moi savoir, bien que mon commentaire de quelques minutes soit probablement une sous-estimation flagrante, mais en quelques heures, oui.
— Tom Gullen
1
Peut-être quelques secondes en fait, voir golubev.com/hashgpu.htm qui utilise le GPU pour calculer comme indiqué "2300M / s de hachages SHA1 par seconde". Avec une gamme complète de 95 caractères ASCII allant de 1 à 6 caractères, nous pouvons le déchiffrer en moins de 6 minutes. Si nous n'avons que des caractères alphanumériques minuscules, jusqu'à 8 caractères de longueur <25 minutes. Avec une base de données de 10000 enregistrements utilisateur, nous avons pu trouver les 4 mots de passe ASCII complets en <200 secondes ((((95 ^ 4) / 2300000000) / 2) * 10000). (Plus de frais généraux que ceux cités, et les vitesses de GPU citées sont probablement des situations idéales).
— Tom Gullen
Oui, le salage ne vous empêche pas de forcer brutalement ce mot de passe. Il est plus difficile pour vous de générer le ((10 ^ 5) * (94 ^ 10)) = 10 ^ 24 si les utilisateurs ont des mots de passe d'environ 10 caractères, ce qui est beaucoup plus difficile que le 10 ^ 19 sans hachage. Encore une fois, il ne s'agit pas de rendre difficile la rupture d'un mot de passe, c'est de rendre impossible la rupture de tous les mots de passe avec une table arc-en-ciel pré-traitée. (et vérifiez mes calculs ici, mais je crois que 10 ^ 25/2300000000/60/60/24/365/1000 = 137869 ~ milinea pour le mot de passe de tout le monde). Si nous voulons des mots de passe plus forts, nous ne les salons pas, nous utilisons des choses comme l'échange de clés Diffie-Hellman.
— Incognito
3

L'idée derrière l'attaque par dictionnaire est que vous prenez un hachage et trouvez le mot de passe, à partir duquel ce hachage a été calculé, sans calcul de hachage. Maintenant, faites de même avec un mot de passe salé - vous ne pouvez pas.

Ne pas utiliser de sel rend la recherche de mot de passe aussi simple que la recherche dans la base de données. L'ajout d'un sel oblige l'attaquant à effectuer un calcul de hachage de tous les mots de passe possibles (même pour l'attachement de dictionnaire, cela augmente considérablement le temps d'attaque).

— Rappel d'Eugene Mayevski
source
Dans le scénario de l'OP, l'attaquant a les sels de la base de données, et devra essayer chaque sel avec chaque entrée dans le "dictionnaire". ...Je pense.
— FrustratedWithFormsDesigner
2

En termes simples: sans salage, chaque mot de passe candidat n'a besoin d'être haché qu'une seule fois pour le vérifier auprès de chaque utilisateur, n'importe où dans «l'univers connu» (collection de bases de données compromises), dont le mot de passe est haché via le même algorithme. Avec le salage, si le nombre de valeurs possibles de sel dépasse sensiblement le nombre d'utilisateurs dans «l'univers connu», chaque mot de passe candidat doit être haché séparément pour chaque utilisateur contre lequel il sera testé.

— supercat
source
2

En termes simples, le salage n'empêche pas un hachage d'attaquer (force brute ou dictionnaire), il ne fait que le rendre plus difficile; l'attaquant devra soit trouver l'algorithme de salage (qui, s'il est mis en œuvre correctement, utilisera plus d'itérations) ou brutforce l'algo, qui, à moins d'être très simple, est presque impossible. Le salage élimine également presque complètement l'option de recherche de table arc-en-ciel ...

— cyber-garde
source
1

Le sel fait la table Rainbow attaques de beaucoup plus difficiles car il rend un hachage de mot de passe beaucoup plus difficile à déchiffrer. Imaginez que vous ayez un horrible mot de passe du numéro 1. Une attaque de table arc-en-ciel le casserait immédiatement.

Imaginez maintenant que chaque mot de passe dans la base de données soit salé avec une longue valeur aléatoire de nombreux caractères aléatoires. Maintenant, votre mauvais mot de passe de "1" est stocké dans la base de données sous la forme d'un hachage de 1 plus un tas de caractères aléatoires (le sel), donc dans cet exemple, la table arc-en-ciel doit avoir le hachage pour quelque chose comme: 1.

Donc, en supposant que votre sel est quelque chose de sécurisé et aléatoire, disons ()% ISLDGHASKLU ( % #% #, la table arc-en-ciel du hacker devrait avoir une entrée pour 1 * ()% ISLDGHASKLU (*% #% #. Utilisant maintenant une table arc-en-ciel même ce simple mot de passe n'est plus pratique.

— Maison Cory
source
Veuillez consulter la mise à jour n ° 2, vous auriez simplement des mots de passe bruts et calculez tous les hachages par rapport aux sels pour chaque enregistrement d'utilisateur.
— Tom Gullen
2
Bien sûr Tom, je suis d'accord, mais le fait est que le pirate informatique doit faire ce processus horrible et chronophage une fois pour chaque mot de passe si le sel est utilisé. Ainsi, le sel rend l'utilisation d'une table arc-en-ciel plus difficile.
— Cory House
3
@Tom Gullen: générer des tables arc-en-ciel salées n'est possible que si des sels à l'échelle du site sont utilisés; le salage par utilisateur rend les attaques de table arc-en-ciel pratiquement inutiles.
— snemarch
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.