Est “double hachage d'un mot de passe de moins en moins sûre juste hacher à la fois?

Est le hachage d'un mot de passe deux fois avant de le ranger plus ou moins en sécurité que juste hacher à la fois?

Quoi je parle, c'est cela:

$hashed_password = hash(hash($plaintext_password));

au lieu de seulement ceci:

$hashed_password = hash($plaintext_password);

Si elle est moins sûr, pouvez-vous fournir une bonne explication (ou un lien vers une)?

Aussi, la fonction de hachage utilisée faire une différence? Faut-il faire une différence si vous mélangez les md5 et sha1 (par exemple) au lieu de répéter la même fonction de hachage?

Note 1: Quand je dis "double hachage" je parle de hachage d'un mot de passe deux fois dans une tentative de le rendre plus lisible. Je ne parle pas de la la technique de résolution des collisions.

Note 2: je sais que j'ai besoin d'ajouter un hasard de sel pour le faire en sécurité. La question est de savoir si le hachage deux fois avec le même algorithme d'aide ou le mal du hachage.

  • Hash(password) et Hash(Hash(password)) sont tout aussi précaire. À la fois l'absence de la notion de Sémantique de Sécurité. Qui est, la sortie est à distinguer de façon aléatoire. Par exemple, MD5("password") est 5f4dcc3b5aa765d61d8327deb882cf99. Je sais que c'est le hash MD5 de password, et il est distinguer de façon aléatoire. Au lieu de cela, vous devez utiliser un HMAC. Son abri et sa PRF.
InformationsquelleAutor Bill the Lizard | 2008-12-07
  1. 255

    Le hachage d'un mot de passe une fois n'est pas sécurisée

    Non, plusieurs hachages sont pas moins sûrs; ils sont une partie essentielle de mot de passe sécurisé à utiliser.

    Itération, la valeur de hachage augmente le temps nécessaire pour qu'un attaquant chaque mot de passe dans la liste de leurs candidats. Vous pouvez facilement augmenter le temps qu'il faut pour attaquer un mot de passe (de quelques heures à plusieurs années.

    Simple itération n'est pas assez

    Simplement le chaînage de hachage de la sortie vers l'entrée n'est pas suffisant pour la sécurité. L'itération devrait avoir lieu dans le contexte d'un algorithme qui préserve l'entropie du mot de passe. Heureusement, il existe plusieurs algorithmes publiés qui ont eu assez de contrôle pour donner confiance dans leur conception.

    Un bon algorithme de dérivation de clé comme PBKDF2 injecte le mot de passe à chaque tour de malaxage, d'atténuer les préoccupations concernant les collisions dans hachage de sortie. PBKDF2 peut être utilisé pour l'authentification par mot de passe comme-est. Bcrypt suit la dérivation de clé avec un cryptage étape; de cette façon, si un moyen rapide pour inverser la dérivation de clé est découvert, un attaquant doit encore achever une attaque à texte clair.

    Comment casser un mot de passe

    Stockés les mots de passe ont besoin de protection contre une attaque hors connexion. Si les mots de passe ne sont pas salés, ils peuvent être divisés avec une pré-calculées d'attaque par dictionnaire (par exemple, à l'aide d'un arc-en-ciel de la Table). Sinon, l'attaquant doit passer du temps à calculer une valeur de hachage pour chaque mot de passe et de voir si elle correspond au hash stocké.

    Tous les mots de passe ne sont pas également probables. Les attaquants pourraient exhaustive de recherche tous les mots de passe courts, mais ils savent que leurs chances pour la force brute de succès diminuent fortement avec chaque personnage supplémentaire. Au lieu de cela, ils utilisent une liste ordonnée de mots de passe. Ils commencent avec "password123" et les progrès réalisés à moins fréquemment les mots de passe utilisés.

    Disons un les attaquants liste est longue, avec 10 milliards de dollars des candidats; supposons également qu'un système de bureau peut calculer 1 million de hachages par seconde. L'attaquant peut faire un test ensemble de la liste est à moins de trois heures si une seule itération est utilisé. Mais si seulement 2000 itérations sont utilisés, que le temps s'étend à presque 8 mois. Pour vaincre un plus sophistiqué attaquant capable de télécharger un programme qui peut exploiter la puissance de leur GPU, par exemple—vous avez besoin de plus d'itérations.

    Combien est assez?

    Le nombre d'itérations à utiliser est un compromis entre la sécurité et de l'expérience utilisateur. Matériel spécialisé qui peut être utilisée par les pirates à bas prix, mais il peut toujours effectuer des centaines de millions d'itérations par seconde. La performance de l' de l'attaquant système détermine combien de temps il faut pour casser un mot de passe donné un certain nombre d'itérations. Mais votre demande n'est pas susceptible d'utiliser ce matériel spécialisé. Combien d'itérations que vous pouvez effectuer sans aggraver les utilisateurs dépend votre système.

    Vous pouvez probablement de laisser les utilisateurs attendre un ¾ de seconde lors de l'authentification. Le profil de votre plate-forme cible, et d'utiliser autant d'itérations que vous pouvez vous permettre. Les plates-formes que j'ai testé (un utilisateur sur un appareil mobile, ou de nombreux utilisateurs sur une plate-forme de serveur) peut soutenir confortablement PBKDF2 avec entre 60 000 et 120 000 itérations, ou bcrypt avec facteur de coût de 12 ou 13 ans.

    Plus de fond

    Lire PKCS #5 pour des informations officielles sur le rôle du sel et des itérations dans le hachage. Même si PBKDF2 a été conçu pour générer des clés de chiffrement des mots de passe, il fonctionne bien comme un hachage de mot de passe pour l'authentification. Chaque itération de bcrypt est plus cher qu'un SHA-2 de hachage, de sorte que vous pouvez utiliser moins d'itérations, mais l'idée est la même. Bcrypt va également un peu au-delà de la plupart des PBKDF2 à base de solutions à l'aide de la dérivée de la clé de chiffrement d'un bien connu en texte brut. Le chiffré résultant est stocké le "hachage", ainsi que de certaines méta-données. Cependant, rien ne vous empêche de faire la même chose avec PBKDF2.

    Voici d'autres réponses que j'ai écrit sur ce sujet:

    • Il est moins sûr mathématiquement, et vous seriez beaucoup mieux à l'aide d'un sleep() que si une lente algorithme
    • Nombre de des chaînes arbitraires: l'infini. nombre possible de valeurs MD5: 2^128. Des travaux de sommeil parce qu'ils sont à l'aide de votre serveur pour authentifier dans RoBorg du scénario. Maintenant, le nombre de chances de mots de passe est de beaucoup inférieur à 2^128, et est donc le nombre de dérivés Md5s, pour que l'argument est discutable.
    • Si une lente algorithme est une pratique acceptée lorsque vous essayez d'empêcher les attaques par dictionnaire contre compromis authentification magasins. La technique est appelée "clé de renforcer" ou "clé d'étirement". Voir en.wikipedia.org/wiki/Key_stretching
    • il n'a pas d'importance comment ralentir votre de la mise en œuvre est, mais comment ralentir un attaquant de mise en œuvre seront les suivantes: si le hachage est lui-même des milliers de fois plus lent, et il faudra un attaquant des milliers de fois, tant de forcer le mot de passe.
    • avec PBKDF2 l'augmentation du nombre d'itérations pour augmenter le temps de traitement, de sorte que n'est pas un spécial bcrypt de la propriété. Bcrypt, d'autre part, n'a pas reçu presque autant cryptological examen HMAC et SHA-2 hachages ont.
    • Sans doute, vous voulez les collisions au sein de la 128 bits de l'espace de 0 à 2^128-1. Si l'algorithme de hachage du 2^128 espace de sortie est parfaite, alors que, théoriquement, vous avez juste un chiffrement de substitution avec un alphabet de 2^128 glyphes.
    • La Substitution de chiffrements sont faibles parce que les distributions de fréquence dans le texte en clair sont propagées vers le texte chiffré. Cela ne s'applique pas ici, où chaque texte "caractère" est tout aussi probable.
    • Les chances de vous venir à travers un md5 de collision par accident, c'est la même que l'obtention de l'intergalactique de la loterie, c'est juste ne va pas arriver. stackoverflow.com/questions/800685/...
    • Ne serait-il pas vrai que si le MD5(K) = [X octet suite] puis MD5(MD5(K)) est MOINS sûr (plus sujettes à la collision) lors de votre K > [X octets], et également sécurisée (c'est à dire redondant/inutile) lorsque K =< [X Octets]? Restreindre le nombre de fois qu'un utilisateur peut retenter un mot de passe est une CRITIQUE mesure de sécurité, mais si vous augmentez l'utilisation de votre CPU 1000 fois pour chaque utilisateur, alors vous avez la solution est ATROCEMENT infranchissables.
    • Donc, (parce que je n'ai pas explicitement de dire ça), vous devriez ne devrait pas être le hachage deux fois, vous devriez privilégier d'autres méthodes qui sont spécifiquement conçus pour limiter le nombre de tentatives, plutôt que de surcharger le CPU pour le faire pour vous.
    • ce n'est pas "ma solution", c'est une pratique largement acceptée, intégré à mot de passe de base de normes de cryptographie comme PKCS #5, et recommandé par les experts comme Robert Morris. Il est extrêmement évolutive, comme la fraction de temps passé à l'authentification des utilisateurs est de petite taille dans une application légitime. Il devient difficile à l'échelle lorsque votre application est en train de craquer les mots de passe, d'où la recommandation. Certes, l'espace de recherche d'une valeur de hachage est plus petite que celle des mots de passe possibles, mais même une 128 bits, l'espace est trop énorme à la recherche par force brute. La menace pour se défendre contre est un dictionnaire hors ligne d'attaque.
    • Je parlais pas de la gêne pour l'utilisateur individuel, mais plutôt le stress qui serait mis sur le serveur si vous avez eu une grande base d'utilisateurs, parce que vous êtes en s'appuyant sur la charge CPU de ralentir le nombre de demandes. Cela signifie que si vous ajoutez plus de puissance CPU, vous êtes à la réduction de la restriction sur ceux de la force brute des attaquants. - Pourtant, vous avez totalement raison sur l'évolutivité et la pratique largement acceptée. J'ai eu tort à propos de presque toutes les choses que j'ai dit dans mes précédents commentaires. Désolé 🙂
    • Pour référence, le sel est censé défendre contre les rainbow tables, pas d'attaques par dictionnaire. Il y a en fait très peu que vous pouvez faire pour se défendre contre les attaques par dictionnaire à l'exception de (1) mettre certaines contraintes sur le mot de passe avant de permettre à un ensemble d'utilisateurs (par exemple, "ne doit pas apparaître dans ma liste de mots communs"), et/ou (2) faire le hachage de mot de passe prendre un temps très long à calculer, qui est le point de plusieurs tours de hachage.
    • Je voulais dire pré-calculé dictionnaire, dans le sens d'un tableau indexé. "Rainbow table" est juste une mise en œuvre spécifique de cette classe générale de l'attaque.
    • Notez que PBKDF2 l'entrer de nouveau le mot de passe et le sel dans chaque étape pour éviter de perdre de l'entropie à de nombreuses tables de hachage. MD5 n'est probablement pas injective sur la 128 bits de l'entrée de l'espace (c'est à dire a des collisions et certaines valeurs de sortie qui ne sont pas atteints) - fonctions de hachage modèle de fonctions aléatoires, pas de permutations aléatoires.
    • En fin de compte beaucoup de ce n'a pas d'importance pour la question, car il ne devrait pas être à l'aide de MD5. Devriez être en utilisant une plus ou SHA BCrypt
    • Tu veux dire PBKDF2 ou bcrypt?
    • Oui, et maintenant, nous sommes les moins mauvais et le mal qu'il y a 15 minutes 😉
    • bcrypt et PBKDF2 étaient toujours là; j'espère qu'ils sont plus importants maintenant. Le point de cette réponse, c'est que le hachage une fois est stupide.
    • et avec ça, je suis d'accord. 🙂
    • La différence entre un itéré de hachage et PBKDF2 est négligeable. Vous perdez de l'entropie, mais il est facile de montrer que pour un idéal de hachage que la perte est assez petite. Si votre langue contre le simple itéré hachages est trop forte. Ce n'est pas des meilleures pratiques, mais ce n'est pas un problème non plus.
    • perdre de l'entropie..." Juste pour s'assurer que je comprends bien: ne nous perdons de l'entropie au cours des itérations, car les fonctions de hachage sont (connu pour être) pas parfaite? Merci!
    • Une fonction de hachage n'est pas une permutation. Donc même pour idéal hachages il y a des collisions coût de l'entropie.
    • Je ne suis pas sûr de ce que vous entendez par "idéal de hachage", mais un "parfait hachage" (en.wikipedia.org/wiki/Perfect_hash_function) les cartes d'un jeu de données d'entrée S sur le S et est une permutation (je pense), avec aucun collisions. Ce que je me demandais à propos de: un hachage cryptographique (qui est pas parfait, car il cartes "infini" sur le S, pour commencer) se comportent comme des "parfait", lors de son entrée set est réduit à être le même que sa sortie est -- ce qui est le cas avec la répétition de hachage --, ou qu'il est impossible (qui requiert de la preuve, au moins je ne suis pas assez intelligent pour juste "voir" que).
    • Si votre fonction est bijective, c'est une permutation et viole les propriétés dont nous avons besoin d'un hachage cryptographique. Donc, nous ne nous attendons pas couramment utilisé hachages pour être bijective, voir Est SHA-512 bijective lorsque le hachage d'un seul 512 bits bloc? sur la crypto.SE pour une variante de cette.
    • Est-il entendu, dans tout cela que l'attaquant connaît l'algorithme de hachage? Est-il vrai que la répétition d'une fonction de hachage n fois rend les choses plus difficile pour l'attaquant s'ils ne connaissent pas la valeur de n?
    • Oui, supposons que l'attaquant sait tout, sauf le mot de passe. Sinon, vous surestimer la sécurité. Ne connaissant pas la valeur de n n'est pas un obstacle important pour l'attaquant; ils continuent juste à l'itération jusqu'à ce qu'ils obtiennent un match. C'est comme un while boucle au lieu d'un for boucle.

    InformationsquelleAutor erickson
  2. 220

    À ceux qui disent que c'est sûr, ils sont corrects en général. "Double" de hachage (ou la logique de l'expansion de cette, itération d'une fonction de hachage) est absolument sûr si c'est bien fait, pour un problème spécifique.

    À ceux qui disent que c'est de l'insécurité, ils sont corrects dans ce cas. Le code qui est affiché dans la question est d'insécurité. Parlons pourquoi:

    $hashed_password1 = md5( md5( plaintext_password ) );
$hashed_password2 = md5( plaintext_password );

    Il y a deux propriétés fondamentales d'une fonction de hachage qui nous préoccupe:

    1. Pré-Image de la Résistance Donnée par une table de hachage $h, il doit être difficile de trouver un message $m tels que $h === hash($m)

    2. Seconde Pré-Image de la Résistance - Donné un message $m1, il devrait être difficile de trouver un autre message $m2 tels que hash($m1) === hash($m2)

    3. Collision Résistance - Il doit être difficile de trouver une paire de messages ($m1, $m2) tels que hash($m1) === hash($m2) (notez que ceci est similaire à la Seconde Pré-Image de la résistance, mais différente, en ce qu'ici, l'attaquant a le contrôle sur les deux messages)...

    Pour le stockage de mots de passe, tout ce qui nous préoccupe vraiment, c'est Pré-Image de la Résistance. Les deux autres serait discutable, car $m1 est le mot de passe utilisateur, nous essayons de garder le coffre-fort. Donc, si l'attaquant a déjà, le hash n'a rien à protéger...

    AVERTISSEMENT

    Tout ce qui suit est basé sur la prémisse que tous nous Pré-Image de la Résistance. Les deux autres propriétés fondamentales des fonctions de hachage ne peut pas (et n'est généralement pas) hold-up de la même manière. Si les conclusions de ce post sont applicable uniquement lors de l'utilisation de fonctions de hachage pour le stockage de mots de passe. Ils ne sont pas applicables en général...

    Nous allons commencer

    Pour les besoins de la présente discussion, nous allons inventer notre propre fonction de hachage:

    function ourHash($input) {
    $result = 0;
    for ($i = 0; $i < strlen($input); $i++) {
        $result += ord($input[$i]);
    }
    return (string) ($result % 256);
}

    Maintenant, il devrait être assez évident que cette fonction de hachage n'. C'sommes ensemble les valeurs ASCII de chaque caractère de l'entrée, et prend alors le modulo de ce résultat avec 256.

    Donc, nous allons le tester:

    var_dump(
    ourHash('abc'), //string(2) "38"
    ourHash('def'), //string(2) "47"
    ourHash('hij'), //string(2) "59"
    ourHash('klm')  //string(2) "68"
);

    Maintenant, nous allons voir ce qui se passe si nous courons à quelques reprises autour d'une fonction:

    $tests = array(
    "abc",
    "def",
    "hij",
    "klm",
);

foreach ($tests as $test) {
    $hash = $test;
    for ($i = 0; $i < 100; $i++) {
        $hash = ourHash($hash);
    }
    echo "Hashing $test => $hash\n";
}

    Que les sorties:

    Hashing abc => 152
Hashing def => 152
Hashing hij => 155
Hashing klm => 155

    Grh, wow. Nous avons généré les collisions!!! Nous allons essayer de vous expliquer pourquoi:

    Voici la sortie de hachage d'une chaîne de chacun et de tous les possible de hachage de sortie:

    Hashing 0 => 48
Hashing 1 => 49
Hashing 2 => 50
Hashing 3 => 51
Hashing 4 => 52
Hashing 5 => 53
Hashing 6 => 54
Hashing 7 => 55
Hashing 8 => 56
Hashing 9 => 57
Hashing 10 => 97
Hashing 11 => 98
Hashing 12 => 99
Hashing 13 => 100
Hashing 14 => 101
Hashing 15 => 102
Hashing 16 => 103
Hashing 17 => 104
Hashing 18 => 105
Hashing 19 => 106
Hashing 20 => 98
Hashing 21 => 99
Hashing 22 => 100
Hashing 23 => 101
Hashing 24 => 102
Hashing 25 => 103
Hashing 26 => 104
Hashing 27 => 105
Hashing 28 => 106
Hashing 29 => 107
Hashing 30 => 99
Hashing 31 => 100
Hashing 32 => 101
Hashing 33 => 102
Hashing 34 => 103
Hashing 35 => 104
Hashing 36 => 105
Hashing 37 => 106
Hashing 38 => 107
Hashing 39 => 108
Hashing 40 => 100
Hashing 41 => 101
Hashing 42 => 102
Hashing 43 => 103
Hashing 44 => 104
Hashing 45 => 105
Hashing 46 => 106
Hashing 47 => 107
Hashing 48 => 108
Hashing 49 => 109
Hashing 50 => 101
Hashing 51 => 102
Hashing 52 => 103
Hashing 53 => 104
Hashing 54 => 105
Hashing 55 => 106
Hashing 56 => 107
Hashing 57 => 108
Hashing 58 => 109
Hashing 59 => 110
Hashing 60 => 102
Hashing 61 => 103
Hashing 62 => 104
Hashing 63 => 105
Hashing 64 => 106
Hashing 65 => 107
Hashing 66 => 108
Hashing 67 => 109
Hashing 68 => 110
Hashing 69 => 111
Hashing 70 => 103
Hashing 71 => 104
Hashing 72 => 105
Hashing 73 => 106
Hashing 74 => 107
Hashing 75 => 108
Hashing 76 => 109
Hashing 77 => 110
Hashing 78 => 111
Hashing 79 => 112
Hashing 80 => 104
Hashing 81 => 105
Hashing 82 => 106
Hashing 83 => 107
Hashing 84 => 108
Hashing 85 => 109
Hashing 86 => 110
Hashing 87 => 111
Hashing 88 => 112
Hashing 89 => 113
Hashing 90 => 105
Hashing 91 => 106
Hashing 92 => 107
Hashing 93 => 108
Hashing 94 => 109
Hashing 95 => 110
Hashing 96 => 111
Hashing 97 => 112
Hashing 98 => 113
Hashing 99 => 114
Hashing 100 => 145
Hashing 101 => 146
Hashing 102 => 147
Hashing 103 => 148
Hashing 104 => 149
Hashing 105 => 150
Hashing 106 => 151
Hashing 107 => 152
Hashing 108 => 153
Hashing 109 => 154
Hashing 110 => 146
Hashing 111 => 147
Hashing 112 => 148
Hashing 113 => 149
Hashing 114 => 150
Hashing 115 => 151
Hashing 116 => 152
Hashing 117 => 153
Hashing 118 => 154
Hashing 119 => 155
Hashing 120 => 147
Hashing 121 => 148
Hashing 122 => 149
Hashing 123 => 150
Hashing 124 => 151
Hashing 125 => 152
Hashing 126 => 153
Hashing 127 => 154
Hashing 128 => 155
Hashing 129 => 156
Hashing 130 => 148
Hashing 131 => 149
Hashing 132 => 150
Hashing 133 => 151
Hashing 134 => 152
Hashing 135 => 153
Hashing 136 => 154
Hashing 137 => 155
Hashing 138 => 156
Hashing 139 => 157
Hashing 140 => 149
Hashing 141 => 150
Hashing 142 => 151
Hashing 143 => 152
Hashing 144 => 153
Hashing 145 => 154
Hashing 146 => 155
Hashing 147 => 156
Hashing 148 => 157
Hashing 149 => 158
Hashing 150 => 150
Hashing 151 => 151
Hashing 152 => 152
Hashing 153 => 153
Hashing 154 => 154
Hashing 155 => 155
Hashing 156 => 156
Hashing 157 => 157
Hashing 158 => 158
Hashing 159 => 159
Hashing 160 => 151
Hashing 161 => 152
Hashing 162 => 153
Hashing 163 => 154
Hashing 164 => 155
Hashing 165 => 156
Hashing 166 => 157
Hashing 167 => 158
Hashing 168 => 159
Hashing 169 => 160
Hashing 170 => 152
Hashing 171 => 153
Hashing 172 => 154
Hashing 173 => 155
Hashing 174 => 156
Hashing 175 => 157
Hashing 176 => 158
Hashing 177 => 159
Hashing 178 => 160
Hashing 179 => 161
Hashing 180 => 153
Hashing 181 => 154
Hashing 182 => 155
Hashing 183 => 156
Hashing 184 => 157
Hashing 185 => 158
Hashing 186 => 159
Hashing 187 => 160
Hashing 188 => 161
Hashing 189 => 162
Hashing 190 => 154
Hashing 191 => 155
Hashing 192 => 156
Hashing 193 => 157
Hashing 194 => 158
Hashing 195 => 159
Hashing 196 => 160
Hashing 197 => 161
Hashing 198 => 162
Hashing 199 => 163
Hashing 200 => 146
Hashing 201 => 147
Hashing 202 => 148
Hashing 203 => 149
Hashing 204 => 150
Hashing 205 => 151
Hashing 206 => 152
Hashing 207 => 153
Hashing 208 => 154
Hashing 209 => 155
Hashing 210 => 147
Hashing 211 => 148
Hashing 212 => 149
Hashing 213 => 150
Hashing 214 => 151
Hashing 215 => 152
Hashing 216 => 153
Hashing 217 => 154
Hashing 218 => 155
Hashing 219 => 156
Hashing 220 => 148
Hashing 221 => 149
Hashing 222 => 150
Hashing 223 => 151
Hashing 224 => 152
Hashing 225 => 153
Hashing 226 => 154
Hashing 227 => 155
Hashing 228 => 156
Hashing 229 => 157
Hashing 230 => 149
Hashing 231 => 150
Hashing 232 => 151
Hashing 233 => 152
Hashing 234 => 153
Hashing 235 => 154
Hashing 236 => 155
Hashing 237 => 156
Hashing 238 => 157
Hashing 239 => 158
Hashing 240 => 150
Hashing 241 => 151
Hashing 242 => 152
Hashing 243 => 153
Hashing 244 => 154
Hashing 245 => 155
Hashing 246 => 156
Hashing 247 => 157
Hashing 248 => 158
Hashing 249 => 159
Hashing 250 => 151
Hashing 251 => 152
Hashing 252 => 153
Hashing 253 => 154
Hashing 254 => 155
Hashing 255 => 156

    Avis, la tendance vers les numéros les plus élevés. Qui s'avère être notre deadfall. L'exécution de la valeur de hachage 4 fois ($hash = ourHash($hash)`, pour chaque élément) des vents jusqu'à nous donner:

    Hashing 0 => 153
Hashing 1 => 154
Hashing 2 => 155
Hashing 3 => 156
Hashing 4 => 157
Hashing 5 => 158
Hashing 6 => 150
Hashing 7 => 151
Hashing 8 => 152
Hashing 9 => 153
Hashing 10 => 157
Hashing 11 => 158
Hashing 12 => 150
Hashing 13 => 154
Hashing 14 => 155
Hashing 15 => 156
Hashing 16 => 157
Hashing 17 => 158
Hashing 18 => 150
Hashing 19 => 151
Hashing 20 => 158
Hashing 21 => 150
Hashing 22 => 154
Hashing 23 => 155
Hashing 24 => 156
Hashing 25 => 157
Hashing 26 => 158
Hashing 27 => 150
Hashing 28 => 151
Hashing 29 => 152
Hashing 30 => 150
Hashing 31 => 154
Hashing 32 => 155
Hashing 33 => 156
Hashing 34 => 157
Hashing 35 => 158
Hashing 36 => 150
Hashing 37 => 151
Hashing 38 => 152
Hashing 39 => 153
Hashing 40 => 154
Hashing 41 => 155
Hashing 42 => 156
Hashing 43 => 157
Hashing 44 => 158
Hashing 45 => 150
Hashing 46 => 151
Hashing 47 => 152
Hashing 48 => 153
Hashing 49 => 154
Hashing 50 => 155
Hashing 51 => 156
Hashing 52 => 157
Hashing 53 => 158
Hashing 54 => 150
Hashing 55 => 151
Hashing 56 => 152
Hashing 57 => 153
Hashing 58 => 154
Hashing 59 => 155
Hashing 60 => 156
Hashing 61 => 157
Hashing 62 => 158
Hashing 63 => 150
Hashing 64 => 151
Hashing 65 => 152
Hashing 66 => 153
Hashing 67 => 154
Hashing 68 => 155
Hashing 69 => 156
Hashing 70 => 157
Hashing 71 => 158
Hashing 72 => 150
Hashing 73 => 151
Hashing 74 => 152
Hashing 75 => 153
Hashing 76 => 154
Hashing 77 => 155
Hashing 78 => 156
Hashing 79 => 157
Hashing 80 => 158
Hashing 81 => 150
Hashing 82 => 151
Hashing 83 => 152
Hashing 84 => 153
Hashing 85 => 154
Hashing 86 => 155
Hashing 87 => 156
Hashing 88 => 157
Hashing 89 => 158
Hashing 90 => 150
Hashing 91 => 151
Hashing 92 => 152
Hashing 93 => 153
Hashing 94 => 154
Hashing 95 => 155
Hashing 96 => 156
Hashing 97 => 157
Hashing 98 => 158
Hashing 99 => 150
Hashing 100 => 154
Hashing 101 => 155
Hashing 102 => 156
Hashing 103 => 157
Hashing 104 => 158
Hashing 105 => 150
Hashing 106 => 151
Hashing 107 => 152
Hashing 108 => 153
Hashing 109 => 154
Hashing 110 => 155
Hashing 111 => 156
Hashing 112 => 157
Hashing 113 => 158
Hashing 114 => 150
Hashing 115 => 151
Hashing 116 => 152
Hashing 117 => 153
Hashing 118 => 154
Hashing 119 => 155
Hashing 120 => 156
Hashing 121 => 157
Hashing 122 => 158
Hashing 123 => 150
Hashing 124 => 151
Hashing 125 => 152
Hashing 126 => 153
Hashing 127 => 154
Hashing 128 => 155
Hashing 129 => 156
Hashing 130 => 157
Hashing 131 => 158
Hashing 132 => 150
Hashing 133 => 151
Hashing 134 => 152
Hashing 135 => 153
Hashing 136 => 154
Hashing 137 => 155
Hashing 138 => 156
Hashing 139 => 157
Hashing 140 => 158
Hashing 141 => 150
Hashing 142 => 151
Hashing 143 => 152
Hashing 144 => 153
Hashing 145 => 154
Hashing 146 => 155
Hashing 147 => 156
Hashing 148 => 157
Hashing 149 => 158
Hashing 150 => 150
Hashing 151 => 151
Hashing 152 => 152
Hashing 153 => 153
Hashing 154 => 154
Hashing 155 => 155
Hashing 156 => 156
Hashing 157 => 157
Hashing 158 => 158
Hashing 159 => 159
Hashing 160 => 151
Hashing 161 => 152
Hashing 162 => 153
Hashing 163 => 154
Hashing 164 => 155
Hashing 165 => 156
Hashing 166 => 157
Hashing 167 => 158
Hashing 168 => 159
Hashing 169 => 151
Hashing 170 => 152
Hashing 171 => 153
Hashing 172 => 154
Hashing 173 => 155
Hashing 174 => 156
Hashing 175 => 157
Hashing 176 => 158
Hashing 177 => 159
Hashing 178 => 151
Hashing 179 => 152
Hashing 180 => 153
Hashing 181 => 154
Hashing 182 => 155
Hashing 183 => 156
Hashing 184 => 157
Hashing 185 => 158
Hashing 186 => 159
Hashing 187 => 151
Hashing 188 => 152
Hashing 189 => 153
Hashing 190 => 154
Hashing 191 => 155
Hashing 192 => 156
Hashing 193 => 157
Hashing 194 => 158
Hashing 195 => 159
Hashing 196 => 151
Hashing 197 => 152
Hashing 198 => 153
Hashing 199 => 154
Hashing 200 => 155
Hashing 201 => 156
Hashing 202 => 157
Hashing 203 => 158
Hashing 204 => 150
Hashing 205 => 151
Hashing 206 => 152
Hashing 207 => 153
Hashing 208 => 154
Hashing 209 => 155
Hashing 210 => 156
Hashing 211 => 157
Hashing 212 => 158
Hashing 213 => 150
Hashing 214 => 151
Hashing 215 => 152
Hashing 216 => 153
Hashing 217 => 154
Hashing 218 => 155
Hashing 219 => 156
Hashing 220 => 157
Hashing 221 => 158
Hashing 222 => 150
Hashing 223 => 151
Hashing 224 => 152
Hashing 225 => 153
Hashing 226 => 154
Hashing 227 => 155
Hashing 228 => 156
Hashing 229 => 157
Hashing 230 => 158
Hashing 231 => 150
Hashing 232 => 151
Hashing 233 => 152
Hashing 234 => 153
Hashing 235 => 154
Hashing 236 => 155
Hashing 237 => 156
Hashing 238 => 157
Hashing 239 => 158
Hashing 240 => 150
Hashing 241 => 151
Hashing 242 => 152
Hashing 243 => 153
Hashing 244 => 154
Hashing 245 => 155
Hashing 246 => 156
Hashing 247 => 157
Hashing 248 => 158
Hashing 249 => 159
Hashing 250 => 151
Hashing 251 => 152
Hashing 252 => 153
Hashing 253 => 154
Hashing 254 => 155
Hashing 255 => 156

    Nous avons réduit de nous-mêmes jusqu'à 8 valeurs... C'est mauvais... Notre fonction d'origine mappé S(∞) sur S(256). C'est, nous avons créé une Surjective Fonction cartographie $input à $output.

    Puisque nous avons une fonction Surjective, nous n'avons aucune garantie de la cartographie pour tout sous-ensemble de l'entrée n'aurez pas de collisions (en fait, dans la pratique, ils le feront).

    C'est ce qui s'est passé ici! Notre fonction est mauvais, mais ce n'est pas pourquoi cela a fonctionné (c'est pourquoi il a travaillé si vite et si complètement).

    La même chose arrive avec MD5. C'cartes S(∞) sur S(2^128). Car il n'y a aucune garantie que l'exécution de MD5(S(output)) sera Injective, ce qui signifie qu'il n'aura pas de collisions.

    TL/DR Section

    Donc, depuis l'alimentation de la sortie arrière de md5 directement, peut générer des collisions, chaque itération va augmenter les chances de collisions. C'est une augmentation linéaire toutefois, ce qui signifie que, bien que l'ensemble de résultats de 2^128 est réduite, il n'est pas réduit significativement assez rapide pour être une faille critique.

    Donc,

    $output = md5($input); //2^128 possibilities
$output = md5($output); //< 2^128 possibilities
$output = md5($output); //< 2^128 possibilities
$output = md5($output); //< 2^128 possibilities
$output = md5($output); //< 2^128 possibilities

    Le plus de fois vous réitérer, la poursuite de la réduction de la va.

    Le Correctif

    Heureusement pour nous, il y a un trivial moyen de résoudre ce problème: Feed-back quelque chose dans les autres itérations:

    $output = md5($input); //2^128 possibilities
$output = md5($input . $output); //2^128 possibilities
$output = md5($input . $output); //2^128 possibilities
$output = md5($input . $output); //2^128 possibilities
$output = md5($input . $output); //2^128 possibilities

    Noter que les autres itérations ne sont pas 2^128 pour chaque valeur de $input. Ce qui signifie que nous pouvons être en mesure de générer $input valeurs que encore entrer en collision sur la ligne (et par conséquent de régler ou de résonner au loin moins de 2^128 sorties possibles). Mais le cas général pour $input est toujours aussi forte que pour un seul tour.

    Attendre, était-il? Nous allons tester cela avec notre ourHash() fonction. Commutation de $hash = ourHash($input . $hash);, pour 100 itérations:

    Hashing 0 => 201
Hashing 1 => 212
Hashing 2 => 199
Hashing 3 => 201
Hashing 4 => 203
Hashing 5 => 205
Hashing 6 => 207
Hashing 7 => 209
Hashing 8 => 211
Hashing 9 => 204
Hashing 10 => 251
Hashing 11 => 147
Hashing 12 => 251
Hashing 13 => 148
Hashing 14 => 253
Hashing 15 => 0
Hashing 16 => 1
Hashing 17 => 2
Hashing 18 => 161
Hashing 19 => 163
Hashing 20 => 147
Hashing 21 => 251
Hashing 22 => 148
Hashing 23 => 253
Hashing 24 => 0
Hashing 25 => 1
Hashing 26 => 2
Hashing 27 => 161
Hashing 28 => 163
Hashing 29 => 8
Hashing 30 => 251
Hashing 31 => 148
Hashing 32 => 253
Hashing 33 => 0
Hashing 34 => 1
Hashing 35 => 2
Hashing 36 => 161
Hashing 37 => 163
Hashing 38 => 8
Hashing 39 => 4
Hashing 40 => 148
Hashing 41 => 253
Hashing 42 => 0
Hashing 43 => 1
Hashing 44 => 2
Hashing 45 => 161
Hashing 46 => 163
Hashing 47 => 8
Hashing 48 => 4
Hashing 49 => 9
Hashing 50 => 253
Hashing 51 => 0
Hashing 52 => 1
Hashing 53 => 2
Hashing 54 => 161
Hashing 55 => 163
Hashing 56 => 8
Hashing 57 => 4
Hashing 58 => 9
Hashing 59 => 11
Hashing 60 => 0
Hashing 61 => 1
Hashing 62 => 2
Hashing 63 => 161
Hashing 64 => 163
Hashing 65 => 8
Hashing 66 => 4
Hashing 67 => 9
Hashing 68 => 11
Hashing 69 => 4
Hashing 70 => 1
Hashing 71 => 2
Hashing 72 => 161
Hashing 73 => 163
Hashing 74 => 8
Hashing 75 => 4
Hashing 76 => 9
Hashing 77 => 11
Hashing 78 => 4
Hashing 79 => 3
Hashing 80 => 2
Hashing 81 => 161
Hashing 82 => 163
Hashing 83 => 8
Hashing 84 => 4
Hashing 85 => 9
Hashing 86 => 11
Hashing 87 => 4
Hashing 88 => 3
Hashing 89 => 17
Hashing 90 => 161
Hashing 91 => 163
Hashing 92 => 8
Hashing 93 => 4
Hashing 94 => 9
Hashing 95 => 11
Hashing 96 => 4
Hashing 97 => 3
Hashing 98 => 17
Hashing 99 => 13
Hashing 100 => 246
Hashing 101 => 248
Hashing 102 => 49
Hashing 103 => 44
Hashing 104 => 255
Hashing 105 => 198
Hashing 106 => 43
Hashing 107 => 51
Hashing 108 => 202
Hashing 109 => 2
Hashing 110 => 248
Hashing 111 => 49
Hashing 112 => 44
Hashing 113 => 255
Hashing 114 => 198
Hashing 115 => 43
Hashing 116 => 51
Hashing 117 => 202
Hashing 118 => 2
Hashing 119 => 51
Hashing 120 => 49
Hashing 121 => 44
Hashing 122 => 255
Hashing 123 => 198
Hashing 124 => 43
Hashing 125 => 51
Hashing 126 => 202
Hashing 127 => 2
Hashing 128 => 51
Hashing 129 => 53
Hashing 130 => 44
Hashing 131 => 255
Hashing 132 => 198
Hashing 133 => 43
Hashing 134 => 51
Hashing 135 => 202
Hashing 136 => 2
Hashing 137 => 51
Hashing 138 => 53
Hashing 139 => 55
Hashing 140 => 255
Hashing 141 => 198
Hashing 142 => 43
Hashing 143 => 51
Hashing 144 => 202
Hashing 145 => 2
Hashing 146 => 51
Hashing 147 => 53
Hashing 148 => 55
Hashing 149 => 58
Hashing 150 => 198
Hashing 151 => 43
Hashing 152 => 51
Hashing 153 => 202
Hashing 154 => 2
Hashing 155 => 51
Hashing 156 => 53
Hashing 157 => 55
Hashing 158 => 58
Hashing 159 => 0
Hashing 160 => 43
Hashing 161 => 51
Hashing 162 => 202
Hashing 163 => 2
Hashing 164 => 51
Hashing 165 => 53
Hashing 166 => 55
Hashing 167 => 58
Hashing 168 => 0
Hashing 169 => 209
Hashing 170 => 51
Hashing 171 => 202
Hashing 172 => 2
Hashing 173 => 51
Hashing 174 => 53
Hashing 175 => 55
Hashing 176 => 58
Hashing 177 => 0
Hashing 178 => 209
Hashing 179 => 216
Hashing 180 => 202
Hashing 181 => 2
Hashing 182 => 51
Hashing 183 => 53
Hashing 184 => 55
Hashing 185 => 58
Hashing 186 => 0
Hashing 187 => 209
Hashing 188 => 216
Hashing 189 => 219
Hashing 190 => 2
Hashing 191 => 51
Hashing 192 => 53
Hashing 193 => 55
Hashing 194 => 58
Hashing 195 => 0
Hashing 196 => 209
Hashing 197 => 216
Hashing 198 => 219
Hashing 199 => 220
Hashing 200 => 248
Hashing 201 => 49
Hashing 202 => 44
Hashing 203 => 255
Hashing 204 => 198
Hashing 205 => 43
Hashing 206 => 51
Hashing 207 => 202
Hashing 208 => 2
Hashing 209 => 51
Hashing 210 => 49
Hashing 211 => 44
Hashing 212 => 255
Hashing 213 => 198
Hashing 214 => 43
Hashing 215 => 51
Hashing 216 => 202
Hashing 217 => 2
Hashing 218 => 51
Hashing 219 => 53
Hashing 220 => 44
Hashing 221 => 255
Hashing 222 => 198
Hashing 223 => 43
Hashing 224 => 51
Hashing 225 => 202
Hashing 226 => 2
Hashing 227 => 51
Hashing 228 => 53
Hashing 229 => 55
Hashing 230 => 255
Hashing 231 => 198
Hashing 232 => 43
Hashing 233 => 51
Hashing 234 => 202
Hashing 235 => 2
Hashing 236 => 51
Hashing 237 => 53
Hashing 238 => 55
Hashing 239 => 58
Hashing 240 => 198
Hashing 241 => 43
Hashing 242 => 51
Hashing 243 => 202
Hashing 244 => 2
Hashing 245 => 51
Hashing 246 => 53
Hashing 247 => 55
Hashing 248 => 58
Hashing 249 => 0
Hashing 250 => 43
Hashing 251 => 51
Hashing 252 => 202
Hashing 253 => 2
Hashing 254 => 51
Hashing 255 => 53

    Il y a toujours une rude modèle là, mais note qu'il n'est plus d'un modèle que notre fonction sous-jacente (qui était déjà très faible).

    Remarquer cependant que 0 et 3 est devenu collisions, même si elles n'étaient pas dans le seul passage. C'est une application de ce que j'ai dit avant (que la collision de la résistance reste le même pour l'ensemble de toutes les entrées, mais de collision itinéraires peuvent s'ouvrir en raison de failles dans l'algorithme sous-jacent).

    TL/DR Section

    Par l'alimentation de l'arrière de l'entrée dans chaque itération, nous briser efficacement toutes les collisions qui peuvent avoir eu lieu dans l'avant itération.

    Par conséquent, md5($input . md5($input)); devrait être (théoriquement au moins) aussi forte que md5($input).

    Est-Ce Important?

    Oui. C'est une des raisons qui PBKDF2 remplacé PBKDF1 dans RFC 2898. Examiner l'intérieur des boucles de deux::

    PBKDF1:

    T_1 = Hash (P || S) ,
T_2 = Hash (T_1) ,
...
T_c = Hash (T_{c-1})

    Où c est le nombre d'itérations, P est le Mot de passe et S est le sel

    PBKDF2:

    U_1 = PRF (P, S || INT (i)) ,
U_2 = PRF (P, U_1) ,
...
U_c = PRF (P, U_{c-1})

    Où PRF est vraiment juste un HMAC. Mais pour nos besoins ici, disons simplement que PRF(P, S) = Hash(P || S) (qui est, le PRF de 2 entrées est le même, grosso modo, comme hachage avec les deux concaténées). C'est très bien pas, mais pour nos fins, il est.

    Donc PBKDF2 maintient la collision de la résistance du sous-jacent Hash fonction, où PBKDF1 ne pas.

    Cravate-ing Tous Ensemble:

    Nous savons de moyens sûrs de l'itération d'un algorithme de hachage. En fait:

    $hash = $input;
$i = 10000;
do {
   $hash = hash($input . $hash);
} while ($i-- > 0);

    Est généralement sûr.

    Maintenant, pour aller dans pourquoi on aurait envie de hachage, nous allons analyser l'entropie mouvement.

    Un hachage prend dans l'ensemble infini: S(∞) et produit une plus petite, de taille constante définie S(n). L'itération suivante (en supposant que l'entrée est passé dans l') cartes S(∞) sur S(n) de nouveau:

    S(∞) -> S(n)
S(∞) -> S(n)
S(∞) -> S(n)
S(∞) -> S(n)
S(∞) -> S(n)
S(∞) -> S(n)

    Avis que le résultat final a exactement la même quantité d'entropie que le premier. L'itération sera pas "rendre plus obscurci". L'entropie est identique. Il n'y a pas la magie de la source d'imprévisibilité (c'est un Pseudo-Aléatoire-Fonction, pas une Fonction Aléatoire).

    Il y a cependant un gain pour l'itération. Il rend le processus de hachage artificiellement plus lent. Et c'est pourquoi l'itération peut être une bonne idée. En fait, c'est le principe de base de la plupart des modernes, les algorithmes de hachage de mot de passe (le fait que de faire quelque chose de plus et plus, il est plus lent).

    Lent, c'est bon, parce que c'est la lutte contre la principale menace pour la sécurité: force brute. Le ralentissement de nous faire de notre algorithme de hachage, la plus difficile, les attaquants doivent travailler à l'attaque des mots de passe volés de nous. Et c'est une bonne chose!!!

    • $output = md5($output); // < 2^128 possibilities --- est-il vraiment le strict <, ou <=?
    • Ce n'est pas à strictement rien. Nous aurions besoin de connaître certains détails extrêmement spécifiques de la fonction sous-jacente (md5() dans ce cas) pour être vraiment sûr. Mais en général, il sera < et pas <=... Rappelez-vous, nous parlons de la taille de l'ensemble des $output pour tous possible $inputs. Donc, si nous avons encore un collision, elle sera <, donc < est le mieux generalizer.
    • "Donc, si nous avons de même une collision, il sera <" --- il n'y a pas de mathématiques la preuve pour cela 🙂
    • oui, il est. Si il ya même une collision, elle cesse d'être une Fonction Injective. Et si vous avez besoin purement Injective fonction pour = (comme toutes les entrées dans S(2^128) aurait besoin d'une carte à une seule sortie dans S(2^128)). Mais avoir un collision signifie qu'il n'est plus Injective, et donc de l'espace de sortie par mandat devient plus petit que l'espace d'entrée (par la définition même de la fonction elle-même)...
    • "S'il y a de même une collision" --- alors, comment voulez-vous savez qu'il y en a un?
    • Merci pour cette idée! Cependant, je me demande si cette collision s'applique également pour les fonctions de hachage où la taille de la sortie est de la même taille que l'état interne, par exemple: est en cours d'exécution SHA512 deux fois de ne pas le même que l'ajout de plus de ronds pour les fonctions de hachage, et, par conséquent, devrait être ok parce que le surjective cartographie ne se produit pas?
    • l'état interne n'est pas question pour cette analyse. La seule, la matière sont d'entrée (tous à moins de 2^128-1) et la sortie (2^10). Donc oui, cela s'applique encore à SHA-512...
    • zerkms: Il est appelé problème d'Anniversaire. Il y a 2^128 hachages md5 (qui est en fait basée sur la combinatoire). Donc, si vous choisissez 2^128 entrées différentes, tous de la génération de hachage unique vous utilisez toutes les tables de hachage. Donc, si vous avez choisi 2^128+1 vous serait laissé avec le seul et tous les hachages utilisé => l'un a le même hash que l'un des 2^128. Il y a donc au moins une collision. Par induction mathématique, vous pouvez le prouver, qu'il est en fait un nombre infini de collisions.
    • Je pense que la question n'est pas sur les collisions en général, mais les collisions dans la stricte ensemble de sortie (2^128 sorties, exactement 128 bits de large). Que pourrait être Injective, mais autant que je sache, un générique de la preuve n'est pas possible (seulement une preuve-par-exemple d'une collision pour un algorithme spécifique). Considérons la fonction de hachage qui retourne simplement l'entrée si elle est de 128 bits (et les tables de hachage contraire). En général, il serait surjective, mais quand la fed de sa sortie, elle serait toujours injective... C'est le point de discorde...
    • Pouvez-vous expliquer ce qu'environ serait la taille de sortie de 1000 itérations de $input = MD5($input)? Pour une itération, c'est 16^32 ~ 3e38. Si MD5 se comporte comme une fonction aléatoire puis pour 1000 itérations, il devrait être autour de 7e35.
    • pour l'effort et le degré d'élaboration, mais les pièces de cette réponse, c'est très très mauvais / trompeuse. Il y a exactement zéro preuve que md5($input . md5($input)) cartes à S(n) et c'est même pas théoriquement correcte. La théorie de corriger l'équation est md5(∞ . md5($input)) = S(n) et depuis $input est loin de l'infini il est tout simplement aucun moyen de prouver que md5($input . md5($input)) a plus d'entropie que md5(md5($input)). Les deux équations sont aussi mauvais l'un et impossible à prouver à la carte de S(n). J'espère vous revoir la réponse puisqu'il est hautement exercés.
    • $hash = hash($input . $hash); Ne serait pas de force brute d'une seule itération de la hash stocké vous donner par exemple "MyPassword5f4dcc3b5aa765d61d8327deb882cf99"? Pourquoi s'embêter à aller plus loin quand je peux lire de l'entrée d'origine à partir du préfixe de la chaîne? Vous avez besoin d'utiliser autre chose que de l'entrée d'origine ou de l'ensemble de l'exercice est futile.
    • Laissez-nous continuer cette discussion dans le chat.
    • Pour ceux qui voudraient gagner du temps en n'ayant pas à aller vérifier comment cette discussion entre Dan & ircmaxell fini, c'est bien fini: Dan accord avec ircmaxell.

    InformationsquelleAutor ircmaxell
  3. 48

    Oui, re-hachage réduit l'espace de recherche, mais non, il n'a pas d'importance - la réduction effective est insignifiant.

    Re-hachage augmente le temps nécessaire à la force brute, mais de le faire que deux fois est également sous-optimale.

    Ce que vous voulez vraiment est de hacher le mot de passe avec PBKDF2 - une méthode qui a prouvé à l'aide d'un hachage sécurisé avec le sel et les itérations. Découvrez cette SORTE de réponse.

    MODIFIER: j'ai presque oublié - NE PAS UTILISER MD5!!!! l'Utilisation moderne de hachage cryptographique, comme le SHA-2 de la famille (SHA-256, SHA-384 et SHA-512).

    • Ou BCrypt, qui fonctionne toujours.
    • d'accord. bcrypt ou scrypt sont de meilleures options.
    • +1 pour la mention de NE PAS UTILISER MD5
    • N'utilisez pas non plus (SHA-2 de la famille), ils peuvent désormais être également craqué facilement, vérifiez crackstation.net pour preuve. Si quoi que ce soit d'utiliser scrypt ou PBKDF2 qui sont fonction de dérivation de clé (KDFs) base de fonctions de hachage cryptographiques.
    • En 2016, Argon2 et scrypt sont celles que tout le monde devrait s'efforcer d'utiliser
    InformationsquelleAutor orip
  4. 10

    Oui - il réduit le nombre de peut-être des chaînes de caractères qui correspondent à la chaîne.

    Comme vous l'avez déjà mentionné, salé hachages sont beaucoup mieux.

    Un article ici: http://websecurity.ro/blog/2007/11/02/md5md5-vs-md5/, tente une preuve pourquoi il est équivalent, mais je ne suis pas sûr qu'avec la logique. En partie, ils supposent qu'il n'y a pas de logiciel d'analyse de md5(md5(texte)), mais, évidemment, il est assez trivial pour produire de l'arc-en-ciel tables.

    Je suis toujours coller de ma réponse qu'il y a de plus petit nombre de md5(md5(texte)) type de hachages que md5(texte) de tables de hachage, ce qui augmente les chances de collision (même si encore peu de probabilité) et la réduction de l'espace de recherche.

    InformationsquelleAutor Rich Bradshaw
  5. 4

    La plupart des réponses sont par des gens sans un arrière-plan dans la cryptographie ou de sécurité. Et ils ont tort. Utilisation d'un sel, si possible unique pour chaque enregistrement. MD5/SHA/etc sont trop rapides, à l'opposé de ce que vous voulez. PBKDF2 et bcrypt sont plus lentes (qui est bon) mais peut être vaincu avec Asic/FPGA/Gpu (très afordable de nos jours). Ainsi, un mémoire-dur algorithme est nécessaire: entrez scrypt.

    Voici un profane explication de sels et de la vitesse (mais pas sur la mémoire-dur algorithmes).

    InformationsquelleAutor alecco
  6. 4

    Je viens de regarder à ce à partir d'un point de vue pratique. Qu'est-ce que le pirate après? Pourquoi, la combinaison de caractères qui, lorsqu'il est mis en travers de la fonction de hachage, génère le désiré de hachage.

    Vous êtes seulement à la sauvegarde de la dernière de hachage, par conséquent, le hacker n'a qu'à bruteforce un hachage. En supposant que vous avez à peu près la même probabilité de tomber sur le désiré de hachage avec chaque bruteforce étape, le nombre de hachages n'est pas pertinent. Vous pourriez faire un million de hachage itérations, et il ne serait pas augmenter ou réduire la sécurité d'un bit, car, à la fin de la ligne, il n'y a toujours qu'un seul de hachage à rompre, et les chances de rupture sont les mêmes que tout hachage.

    Peut-être que les précédentes affiches pense que l'entrée est pertinent; il ne l'est pas. Aussi longtemps que ce que vous mettez dans la fonction de hachage génère le désiré de hachage, il va passer à travers, d'entrée correcte ou incorrecte d'entrée.

    Maintenant, tables arc-en-ciel sont une autre histoire. Depuis une rainbow table transporte uniquement des crus des mots de passe, le hachage deux fois peut être une bonne mesure de sécurité, car un arc-en-ciel de la table qui contient tous les hash de tous les hash serait trop grande.

    Bien sûr, je ne suis qu'en considérant l'exemple l'OP donné, où c'est juste du texte brut mot de passe haché. Si vous incluez le nom d'utilisateur ou un sel dans la table de hachage, c'est une autre histoire; de hachage deux fois, c'est tout à fait inutile, puisque l'arc-en-ciel de la table, ce serait déjà trop grande pour être pratique et contenir le droit de hachage.

    De toute façon, pas un expert en sécurité ici, mais c'est juste ce que j'ai compris de mon expérience.

    • Cette réponse est fausse dans tous les domaines. 1. Sachant que l'avant-dernier de hachage fournit pas de valeur pour un attaquant, car l'entrée d'un itéré de hachage est le mot de passe, qui est ensuite hachée de nombreuses fois (pas une seule fois). 2. L'espace d'entrée est des mots de passe, l'espace de sortie est des mots de passe hachés. L'espace de typique mots de passe est beaucoup plus petit que l'espace de sortie. 3. Rainbow tables pour non salé double-mots de passe hachés sont pas plus grandes qu'un arc-en-ciel tableaux de beurre non-salé, seul les mots de passe hachés. 4. Les noms d'utilisateur sont de faible entropie, un bon sel est aléatoire. 5. Le salage ne remplace pas d'itération. Vous avez besoin des deux.
    InformationsquelleAutor Pat
  7. 3

    De ce que j'ai lu, c'est peut être recommandé de re-hachage du mot de passe des centaines ou des milliers de fois.

    L'idée est que si vous pouvez lui faire prendre plus de temps pour encoder le mot de passe, c'est plus de travail pour un attaquant d'exécuter à travers de nombreux essais pour deviner le mot de passe. Qui semble être à l'avantage de re-hachage-non pas qu'il est plus cryptographique sécurisé, mais il prend simplement plus de temps pour générer une attaque par dictionnaire.

    Bien sûr ordinateurs plus rapides de tous les temps, cet avantage diminue avec le temps (ou vous oblige à augmenter les itérations).

    InformationsquelleAutor Bill Karwin
  8. 2

    Personnellement, je ne voudrais pas ennuyer avec plusieurs hashses, mais je m'assurerais de également de hachage le nom d'utilisateur (ou un autre champ d'ID Utilisateur) et le mot de passe si deux utilisateurs avec le même mot de passe ne finirez pas avec le même hash. Aussi, je serais probablement jeter des autres constantes de chaîne dans la chaîne d'entrée trop pour faire bonne mesure.

    $hashed_password = md5( "xxx" + "|" + user_name + "|" + plaintext_password);
    • En fait, il devrait être une chaîne de caractères générés aléatoirement pour chaque utilisateur, pas une constante.
    • Une constante œuvres secrètes (et est plus facile à travailler), si vous jetez dans le nom d'utilisateur comme le suggère. Qui produit essentiellement du hasard clé spécifique à l'utilisateur.
    • Une constante secret de sel est la sécurité par l'obscurité. Si le "secret" sort que vous êtes à l'aide de "xxx" + nom d'utilisateur + mot de passe, puis un attaquant n'a même pas besoin de données de vos tables de lancer une attaque contre elle.
    • Je ne pense pas que c'est la sécurité par l'obscurité. La raison de l'utilisation d'un sel, c'est que vous ne pouvez pas calculer un arc-en-ciel de la table à l'encontre de plusieurs de hachages md5 simultanément. La construction de l'un pour les "xxx"+mot de passe (même sel) se fait une fois. La construction d'une table pour "xxx"+nom d'utilisateur+mot de passe est pire que de force brute.
    • les noms d'utilisateur ne sont pas un secret. Si le "secret" de sel xxx est utilisé, l'attaque est réduite à la construction d'un dictionnaire à l'attaque d'un nom d'utilisateur spécifique. Si vous utilisez aléatoire sels ensuite votre base de données devra être compromise avant même l'attaque serait possible.
    • le Lézard: "l'attaque est réduite à la construction d'un dictionnaire à l'attaque d'un nom d'utilisateur spécifique" est juste une attaque par force brute (en réalité, même le pire, car en plus de l'informatique de tous les hachages de vous avoir à les stocker), de sorte que le sel fonctionne parfaitement dans ce cas.
    • Wow, je commence à me sentir un petit peu naïf/ignorants sur ce sujet! Ce que le diable est un arc-en-ciel de la table? lol je suis la recherche de ces commentaires un peu dur à suivre, pas sûr de ce que nous sommes en supposant que le pirate a accès et comment ils attaquent. Je suppose que j'ai besoin de faire plus de recherche sur ce! 🙂
    • Daniel, un arc-en-ciel de la table est un précalculées liste des hachages et ce texte en clair est le fait de ceux des hachages.
    • le problème avec cet argument est qu'il suppose que brute-force est lente... Donc non, vous n'avez pas à stocker les tables de hachage. Et compte tenu de courant, le taux d'attaque pour md5() sont de l'ordre de 180 milliards de dollars par seconde, même la sécurité de votre environnement 9 caractère de mot de passe va tomber dans environ 20 jours (différents cas, de chiffres et de symboles, à 50% de chance de frapper à elle). La raison de ne pas utiliser "les noms d'utilisateur", c'est qu'un autre site peut être aussi bien, et puis un attaquant pourrait amortir l'attaque contre les deux hachages dans le même temps (en supposant que vous utilisez un autre passe sur chaque site)... Aléatoire FTW
    • attaquant pourrait amortir la recherche uniquement si les hachages à partir de différents sites qui ont le même préfixe commun, donc si le "xxx" pièce est unique, il va de feuille. Et oui, MD5 est rapide, mais la question était sur simple vs double hachage et rien que cela ne change pas l'ordre de grandeur de calcul nécessaire, à la différence par exemple bonne clé d'étirement.
    • Ne pas utiliser MD5 à tous.

    InformationsquelleAutor CodeAndCats
  9. 2

    Nous supposons que vous utilisez l'algorithme de hachage: calculer rot13, prendre la première à 10 caractères. Si vous n'avez que deux fois (ou même 2000 fois) il est possible de faire une fonction qui est plus rapide, mais qui donne le même résultat (à savoir il suffit de prendre les 10 premiers caractères).

    De même, il peut être possible de faire un rapide fonction qui donne le même résultat que plusieurs reprises d'une fonction de hachage. Donc, votre choix de la fonction de hachage est très important: comme le rot13 exemple, il n'est pas donné qui se répète de hachage permettront d'améliorer la sécurité. Si il n'y a pas de recherche en disant que l'algorithme est conçu pour les utiliser, alors il est plus sûr de supposer qu'il ne sera pas vous donner une protection supplémentaire.

    Qui a dit: Pour tous, mais le plus simple des fonctions de hachage, il sera plus susceptible de prendre la cryptographie experts pour calculer la plus rapide des fonctions, donc si vous êtes à la protection contre les attaquants qui n'ont pas accès à la cryptographie les experts, il est probablement plus sûr dans la pratique à l'utilisation répétée fonction de hachage.

    InformationsquelleAutor Ole Tange
  10. 1

    En général, il n'apporte aucune sécurité supplémentaire à double hachage ou double chiffrer quelque chose. Si vous pouvez rompre le hachage une fois, vous pouvez le casser à nouveau. Il ne fait généralement pas mal de sécurité pour ce faire, cependant.

    Dans votre exemple de l'utilisation de MD5, comme vous le savez probablement il y a quelques problèmes de collision. "Double Hachage" n'a pas vraiment d'aider à protéger contre ce, depuis la même collisions produira toujours le même hash, que vous pouvez ensuite MD5 de nouveau pour obtenir le second hachage.

    Ce n'protéger contre les attaques par dictionnaire, comme ceux de "renverser le MD5-bases de données", mais le fait de saler.

    Sur une tangente, Double cryptage quelque chose n'assure pas une sécurité supplémentaire, car il n'est de se traduire par une clé qui est une combinaison de deux touches réellement utilisée. Donc, l'effort de trouver la "clé" n'est pas doublé parce que les deux touches ne sont pas réellement besoin d'être trouvé. Ce n'est pas vrai pour le hachage, parce que le résultat de la table de hachage n'est généralement pas de la même longueur que l'entrée d'origine.

    • Tout à fait correct, mais je veux juste noter que l'effet de la forte résistance à la collision de compromis sur le MD5 est soufflé un peu hors de proportion-la plupart des scénarios que l'utilisation de la crypto fonctions de hachage ne pas reposer sur une forte résistance à la collision, juste la faiblesse de la résistance. Ils ne sont pas affectés par cette vulnérabilité.
    InformationsquelleAutor SoapBox
  11. 1

    Que plusieurs réponses dans cet article suggèrent, il ya certains cas où il peut améliore la sécurité et d'autres où elle vraiment ça fait mal. Il y a une meilleure solution qui vous permettra certainement d'améliorer la sécurité. Au lieu de doubler le nombre de fois où vous calculer le hachage, le double de la taille de votre sel, ou le double du nombre de bits utilisés int, la valeur de hachage, ou faire les deux! Au lieu de SHA-245, sauter jusqu'à SHA-512.

    • Ceci ne répond pas à la question.
    • Double hachage n'est pas la valeur de l'effort, mais en doublant votre de hachage de taille est. Je pense que c'est un précieux point.
    InformationsquelleAutor Stefan Rusek
  12. 1

    Double hachage fait sens pour moi que si je le hachage du mot de passe sur le client, puis enregistrez le hachage (avec du sel) de hachage sur le serveur.

    De cette façon, même si quelqu'un a piraté son chemin dans le serveur (ce qui en ignorant les consignes de sécurité SSL fournit), il ne peut toujours pas obtenir de l'effacer les mots de passe.

    Oui, il va avoir les données nécessaires à la brèche dans le système, mais il ne serait pas en mesure d'utiliser les données de compromis à l'extérieur des comptes de l'utilisateur. Et les gens sont connus pour utiliser le même mot de passe pour presque rien.

    La seule manière qu'il pourrait obtenir à l'effacer les mots de passe est d'installer un keygen sur le client - et ce n'est pas votre problème.

    Donc en bref:

    1. La première de hachage sur le client protège vos utilisateurs dans un " serveur violation scénario.
    2. Le second hachage sur le serveur sert à protéger votre système si quelqu'un a obtenu une prise de votre sauvegarde de base de données, donc il ne peut pas utiliser ces mots de passe pour vous connecter à vos services.
    • +1 j'ai été en attente pour voir une réponse comme celle-ci, parce que j'ai pensé la même situation où vous ne voulez pas stocker de la plaine de texte mot de passe sur le client, mais aussi ne pas envoyer le dernier mot de passe crypté sur le fil pour faire une simple comparaison de la DB.
    • N'aide pas pour les applications web. si votre serveur est compromis, le code de votre serveur envoie au client est également compromise. L'attaquant va désactiver votre côté client, le hachage et la capture raw mots de passe.
    InformationsquelleAutor Vedran
  13. 0

    L'inquiétude à propos de la réduction de l'espace de recherche est mathématiquement correct, bien que l'espace de recherche reste suffisamment grand que pour toutes fins pratiques (en supposant que vous utilisez sels), à 2^128. Cependant, puisque nous parlons des mots de passe, le nombre de possibilités de 16 chaînes de caractères (alphanumériques, casquettes question, un peu de symboles jetés dans) est d'environ 2^98, selon mon dos de l'enveloppe des calculs. Donc, la perception de la diminution de l'espace de recherche n'est pas vraiment pertinent.

    A côté de cela, il n'y a vraiment aucune différence, numériquement parlant.

    Bien qu'il y est un crypto primitif appelé un "hash de la chaîne", une technique qui vous permet de faire des trucs cool, comme la divulgation d'une clé de signature après avoir été utilisé, sans sacrifier l'intégrité de ce système, étant donné peu de temps de synchronisation, ce qui vous permet à proprement contourner le problème initial de la distribution des clés. Fondamentalement, vous précalculer un grand nombre de tables de hachage de hachages - h(h(h(h....(h(k))...))) , utilisez la n-ième valeur de signe, après un intervalle défini, vous envoyez la clé et de le signer à l'aide de la clé (n-1). Le recepients pouvez maintenant vérifier que vous avez envoyé à tous les messages précédents, et personne ne peut le faux votre signature, étant donné que la période pour laquelle elle est valable a passé.

    Re-hachage des centaines de milliers de fois, comme la Loi l'indique est juste un gaspillage de votre cpu.. utiliser une clé plus longue si vous êtes préoccupé par les gens de rupture de 128 bits.

    • Re-hachage est précisément au sujet de ralentir le hachage. C'est une fonctionnalité de sécurité de mot de passe de base de la cryptographie. Voir les liens pour PCKS5 et PBKDF2.
    InformationsquelleAutor SquareCog
  14. -1

    Double hachage est moche parce qu'il est plus que probable que l'attaquant a construit un tableau à venir avec la plupart des tables de hachage. Mieux, c'est le sel de votre hache, et mélanger les hachages ensemble. Il y a aussi de nouveaux schémas de "signer" les hachages (essentiellement le salage), mais de manière plus sécurisée.

    InformationsquelleAutor Sargun Dhillon
  15. -1

    Oui.

    Absolument ne pas utiliser plusieurs itérations d'un classique de fonction de hachage, comme md5(md5(md5(password))). Au meilleur vous obtiendrez une augmentation marginale de la sécurité (un schéma comme cette offre guère de protection contre un GPU attaque; il suffit de pipeline.) Au pire, vous réduisez votre hash de l'espace (et donc la sécurité) à chaque itération que vous ajoutez. En matière de sécurité, il est sage de supposer le pire.

    Ne utiliser un mot de passe a été conçu par une autorité cryptographe pour être efficace, un hachage de mot de passe, et résistant à la fois à la force brute et de l'espace-temps des attaques. Ces inclure bcrypt, scrypt, et dans certaines situations PBKDF2. La glibc SHA-256-en fonction de hachage est également acceptable.

    InformationsquelleAutor hobbs
  16. -1

    Je vais aller sur une branche et dire que c'est plus sûr, dans certaines circonstances, à ne pas downvote moi encore si!

    Mathématique /cryptographiques majeures point de vue, c'est moins sûr, pour des raisons que je suis sûr que quelqu'un va vous donner des explications plus claires que j'ai pu.

    Cependant, il existe de grandes bases de données de hachage MD5, qui sont plus susceptibles de contenir le "texte" mot de passe que le MD5 de il. Par double hachage vous êtes à la réduction de l'efficacité de ces bases de données.

    Bien sûr, si vous utilisez un sel puis cet avantage (désavantage?) s'en va.

    InformationsquelleAutor Greg