Question:
Pourquoi le sel n'aurait-il pas empêché le piratage des mots de passe LinkedIn?
pepsi
2012-06-11 18:36:26 UTC
view on stackexchange narkive permalink

Dans cette interview publiée sur Krebs on Security, cette question a été posée et a répondu:

BK: J'ai entendu des gens dire, vous savez que cela le ferait probablement Cela ne s'est pas produit si LinkedIn et d'autres avaient salé les mots de passe - ou ajouté un certain caractère aléatoire à chacun des mots de passe, obligeant ainsi les attaquants à dépenser plus de ressources pour déchiffrer les hachages de mots de passe. Êtes-vous d'accord avec ça?

Ptacek: C'est en fait une autre idée fausse, l'idée que le problème est que les mots de passe n'étaient pas salés. Mots de passe UNIX, et ils ont été salés pour toujours, depuis les années 70, et ils ont été piratés pour toujours. L'idée d'un sel dans votre mot de passe est une solution des années 70. Dans les années 90, lorsque les gens pénétraient par effraction sur les serveurs UNIX, ils volaient le fichier de mot de passe caché et le déchiffraient. Invariablement, lorsque vous perdez le serveur, vous perdez les mots de passe sur ce serveur.

Ptacek n'explique pas vraiment pourquoi c'est le cas - il dit seulement que salt n'a pas empêché ce type d'attaque dans le passé.

Je crois comprendre que salt ne peut empêcher le pré-calcul des hachages de mot de passe qu'à cause de l'espace nécessaire pour stocker les hachages précalculés. Mais si vous avez compromis le système, vous aurez à la fois le sel et le hachage. Ainsi, le temps d'attaque du dictionnaire par le hachage ne change pas de manière significative (juste une concaténation supplémentaire du sel avec le mot du dictionnaire).

Ma compréhension est-elle correcte?

Bien sûr, cela dépend de la taille du sel et de sa visibilité. Si vous utilisez les anciens sels Unix, il n'y en a que 4096 et ils sont stockés avec les hachages, donc un attaquant peut toujours calculer des tables arc-en-ciel et savoir laquelle utiliser. Cela rend le travail plus difficile, mais toujours réalisable avec des tables arc-en-ciel et beaucoup plus facile que la force brute. Maintenant, si LinkedIn utilisait des sels pseudo-aléatoires de 256 bits et ne stockait pas les sels ou les graines dans la base de données, cela aurait empêché les tables arc-en-ciel *** et *** les outils de récupération / d'avertissement comme leakedin.org
Huit réponses:
TwentyMiles
2012-06-11 23:46:46 UTC
view on stackexchange narkive permalink

Krebs fait suite à cette question et Ptacek clarifie ce qu'il voulait dire:

BK: D'accord. Donc, si la faiblesse n'est pas avec la force de l'algorithme cryptographique, et pas avec le manque de sel ajouté aux mots de passe hachés, quelle est la réponse?

Ptacek: Dans le cas de LinkedIn, et avec de nombreux autres sites , le problème est qu'ils utilisent le mauvais type d'algorithme. Ils utilisent un hachage cryptographique, lorsqu'ils ont besoin d'utiliser un hachage de mot de passe.

Dans les prochains paragraphes, il en explique également les raisons. Le long et le court est que SHA1, avec ou sans sel, est beaucoup trop rapide pour être utilisé comme hachage de mot de passe. Il est si rapide que lorsqu'il est calculé à l'aide d'un GPU ou de quelque chose de similaire, vous pouvez forcer brutalement des dizaines de milliers de hachages par seconde. Comme expliqué plus loin dans l'interview, LinkedIn aurait dû utiliser bcrypt, qui est un hachage adaptatif qui aurait ralenti le temps de force brute de l'ordre de 10 secondes de hachage par seconde.

Ahh, avec cette déclaration, la réponse de Ptacek a un peu plus de sens. Je me souviens qu'il faut toujours avoir une vue d'ensemble avant de juger.
* dizaines * de hachages par seconde sur un GPU? Si cela était vraiment vrai, les systèmes se connectant et créant des centaines de comptes par seconde (comme LinkedIn) auraient besoin de plusieurs dizaines de serveurs juste pour calculer le hachage. Pas vraiment faisable. Même avec Blowfish, un GPU peut distribuer * des millions * de hachages par seconde
@Razor - bcrypt vous permet de définir un «facteur de travail» pour décider de la puissance de calcul nécessaire pour calculer le hachage, afin que vous puissiez décider du juste compromis entre vitesse et sécurité. (Vous pouvez également augmenter ce nombre à mesure que les ordinateurs deviennent plus rapides.) Cela dit, si vous disposez de suffisamment de puissance de serveur pour que votre site fonctionne, le hachage des mots de passe n'en sera qu'une infime partie.
Notez également que bcrypt ** utilise ** des sels - http://stackoverflow.com/questions/6832445/how-can-bcrypt-have-built-in-salts
Notez également que la fonction d'auto-salt de BCrypt n'est pas vraie pour toutes les implémentations; plus particulièrement, l'implémentation PHP nécessite une valeur salt comme l'un des paramètres d'entrée.
SHA1 n'est pas un chiffrement, c'est un hachage. Cela me fait remettre en question les connaissances de Ptacek dans le domaine.
Ne devriez-vous pas utiliser [scrypt] (http://www.tarsnap.com/scrypt.html) à la place?
@Zolomon - Jetez un œil à la question SE que j'ai liée dans ma réponse. C'était peut-être un peu caché, donc j'ai changé toute la phrase contenant en un hyperlien. Essentiellement, l'argument de bcrypt par rapport à scrypt est que scrypt est encore très nouveau, et comme il n'y a pas d'attaques connues contre bcrypt, vous devriez privilégier bcrypt par rapport à scrypt car il y a eu plus d'analyses et de tests effectués dessus.
@Ramhound Où prétend-il que c'est un cryptage?
Je pense qu'il est beaucoup trop facile de dire "Devrait utiliser bcrypt" après coup. Non, _ne devrait pas avoir volé votre DB_.
@NathanLong "vous pouvez aussi augmenter ce nombre à mesure que les ordinateurs deviennent plus rapides" Cela n'a aucun sens, à moins que vous ne vouliez demander à tous les utilisateurs de choisir tous les nouveaux mots de passe (tous les hachages changeront).
@bobobobo - pourquoi? Si vous voulez passer de X tours de hachage à X + N tours, vous pouvez simplement ressasser tous vos mots de passe existants N fois et les enregistrer. À partir de là, lorsque quelqu'un fournit un mot de passe en texte brut, vous exécutez des tours X + N et comparez le résultat. Voir http://crypto.stackexchange.com/a/3021
@NathanLong Vous ne pouvez pas augmenter le facteur de travail de bcrypt / scrypt / pbkdf2 * sans * le texte en clair, ce qui signifie que vous ne pouvez mettre à jour le hachage qu'à la prochaine connexion (ce qui devrait être assez bon en pratique, du moins dans la plupart des cas). IIRC, c'est une fonctionnalité souhaitée pour SHA-3.
@Kitsune - il semble que vous ayez raison et que j'avais tort. Discussion ici: http://security.stackexchange.com/questions/15847/is-it-possible-to-increase-the-cost-of-bcrypt-or-pbkdf2-when-its-already-calcula
@bobobobo, vous oubliez la solution évidente: vous attendez que l'utilisateur se reconnecte, puis mettez à jour le mot de passe. Vous avez l'original parce que l'utilisateur vous l'a donné. Vous n'avez pas besoin de lui demander de le changer.
@chacham15 Cependant, demander à l'utilisateur de modifier son mot de passe est une bonne idée au cas où un attaquant aurait éventuellement accès aux hachages plus anciens et plus vulnérables.
Hendrik Brummermann
2012-06-12 00:18:13 UTC
view on stackexchange narkive permalink

Examinons d'abord la question du sel, puis le problème de la vitesse:

Salt, attaques par dictionnaire et tables arc-en-ciel

Un sel aide massivement contre les attaques par dictionnaire dans le cas courant d'un attaquant ayant accès à plus d'un hachage de mot de passe.

Sans sel, un attaquant triera tous les hachages. Il hachera le premier mot du dictionnaire de mots de passe et vérifiera si le hachage calculé est dans sa liste triée de hachages volés . Avec un peu de chance, il a déjà eu accès à plusieurs comptes.

Mais avec un sel , il doit attaquer chaque compte séparément .

Les tables arc-en-ciel ne sont qu'un cas particulier d'attaques par dictionnaire, dans le sens où elles ont été effectuées avant l'attaque et sont prêtes à être utilisées.

Il est important de noter: coller un une chaîne aléatoire constante pour tous les mots de passe rendra les tables arc-en-ciel préconstruites inutiles. Mais c'est toujours une mauvaise idée en raison du problème de parallélisme décrit précédemment.

Vitesse, algorithmes pour les documents vs pour les mots de passe

En plus de ne pas utiliser un sel, LinkedIn a utilisé un algorithme de hachage qui est très rapide, et peut être exécuté sur un matériel spécial pour encore plus de vitesse supplémentaire. Ce matériel spécial n'est pas exotique mais fait partie des cartes graphiques courantes.

Robert David Graham a publié les détails de son travail de craquage, y compris les données de performance:

2 milliards par seconde avec la Radeon HD 7970. Un mot de passe de 6 [caractères] [en] 500 secondes [...] avec force brute.

Le cas d'utilisation d'origine des algorithmes de hachage était de signer des documents. Par conséquent, être rapide était un objectif de conception.

Les algorithmes de hachage modernes pour les mots de passe sont conçus pour être relativement lents . Un moyen simple de les ralentir est d'utiliser la fonction de hachage de manière répétée. ShaCrypt et BCrypt sont de tels algorithmes. Ils accordent une attention particulière pour éviter le traitement parallèle et être résistants aux attaques pré-image sur un seul tour.

Scrypt va encore plus loin: en plus d'être lent, il nécessite beaucoup de mémoire (par exemple 16 Mo pour la configuration par défaut). Le matériel spécialisé n'a généralement accès qu'à environ 1 Ko de mémoire interne rapide. L'accès à la mémoire centrale est lent. Par conséquent, la construction d'un cracker scrypt rapide dans le matériel coûte très rapidement.

L'utilisation d'une chaîne aléatoire constante comme sel rendra les tables arc-en-ciel préconstruites inutiles (à moins que l'une des tables arc-en-ciel n'ait utilisé la même chaîne aléatoire que son sel), mais c'est beaucoup moins utile que d'utiliser un sel différent pour chaque mot de passe. En utilisant un sel constant, un attaquant peut créer un dictionnaire de hachage en utilisant ce sel et compromettre tous les comptes en utilisant un mot de passe dans le dictionnaire en un seul passage. Tous les comptes utilisant "mot de passe" comme mot de passe seraient découverts en un seul passage. Varier le sel obligerait l'attaquant à rompre chaque compte séparément, ce qui rendrait le système beaucoup plus sécurisé.
@MajorMajor, c'est exactement ce que j'ai écrit, n'est-ce pas?
@MajorMajor, ah vous l'avez obtenu dans l'autre sens. Pour le cas du «sel» constant, je propose ceci: trier la base de données de mots de passe et utiliser celle-ci pour rechercher les hachages fraîchement calculés. C'est beaucoup plus efficace que de créer d'abord une table arc-en-ciel dédiée, avec de nombreuses entrées qui ne sont de toute façon pas dans la base de données de mots de passe.
Hendrik, ce que j'ai écrit est d'accord avec ce que vous avez écrit, mais je voulais clarifier votre commentaire selon lequel l'utilisation de sels constants rendrait les tables pré-construites inutiles. Avec de minuscules sels, les tables ont peut-être été pré-construites de toute façon et avec d'énormes sels, vous craquez toujours tous les comptes avec le même mot de passe en une seule fois. Par exemple, si vous avez un compte sur le système, vous pouvez immédiatement trouver toutes les autres personnes qui utilisent le même mot de passe que vous. J'étais, comme toujours, inquiet qu'un débutant puisse mal comprendre une remarque et finir par faire quelque chose de stupidement peu sûr.
Rory Alsop
2012-06-11 19:05:04 UTC
view on stackexchange narkive permalink

Vous avez raison, mais cela ne change rien au fait qu'il est essentiel d'utiliser un sel. Dans ce cas, les attaquants ont mis la main sur les mots de passe hachés, afin qu'ils puissent soit utiliser une table arc-en-ciel, soit lancer une attaque par force brute ou par dictionnaire.

  • Une table arc-en-ciel vous donnera tous les mots de passe (jusqu'à la taille et la complexité du tableau) dans un laps de temps très court.

  • De même, une attaque par dictionnaire vous donnera les mots de passe qui sont dans les dictionnaires.

  • Le forçage brutal vous donnera rapidement les mots de passe courts et simples, mais le temps nécessaire pour obtenir les plus longs devient rapidement si prohibitif que les utilisateurs avec des mots de passe longs sont encore relativement sûrs.

Donc, un sel supprime ce premier ensemble de possibilités, forçant les attaquants à utiliser des solutions de dictionnaire et de force brute, ce qui rend les utilisateurs plus sûrs.

user10211
2012-06-11 19:02:43 UTC
view on stackexchange narkive permalink

Ce qu'un sel fait, c'est qu'il rend les tables arc-en-ciel inutiles, ce qui ralentit les tentatives de force brute sur le mot de passe.

Définition de la table arc-en-ciel:

Une table arc-en-ciel est une table précalculée pour inverser les fonctions de hachage cryptographiques, généralement pour craquer les hachages de mots de passe.

Sans sel, un attaquant pourrait facilement utiliser une table arc-en-ciel pré-générée contenant des millions de mots de passe et leur équivalent haché et comparez-le au mot de passe.

Avec un salt, chaque mot de passe oblige l'attaquant à générer une toute nouvelle table arc-en-ciel.

Cela n'a aucun impact sur les attaques par dictionnaire - simple et évidente basée sur un dictionnaire les mots de passe comme le mot de passe seront facilement piratés avec ou sans sel.

Un sel DEVRAIT cependant être utilisé. Le craquage de mot de passe est une question de temps / effort. Aucun mot de passe / hachage n'est invincible. Il s'agit de forcer l'attaquant à passer plus de temps qu'il n'est disposé à passer sur vos tables de mots de passe.

"_Avec un sel, chaque mot de passe oblige l'attaquant à générer une toute nouvelle table arc-en-ciel._" alors pourquoi s'embêter avec des tables ???
En ce qui concerne John the Ripper (le logiciel que j'utilise), le craquage de mot de passe se déroule comme suit. Prend la liste des mots de passe d'entrée, le hachage, la comparaison avec le hachage connu. Ce n'est pratiquement pas différent de générer des tables arc-en-ciel pour chaque hachage salé et de le comparer.
Donc, si vous utilisiez un mot de passe de style CorrectHorseBatteryStaple et que la table était salée, votre mot de passe serait probablement sûr, car ils forceraient brutalement tous les "fruits à portée de main" et ne s'inquiéteraient probablement pas des 5% des utilisateurs utilisé les mots de passe les plus sécurisés. Heck, les pirates pourraient être heureux de ne renforcer brutalement que 20% environ des mots de passe.
@TerryChia "_is n'est pratiquement pas différent de générer des tables arc-en-ciel pour chaque hachage salé et de le comparer._" Hug? C'est totalement différent. La génération de tables nécessitait beaucoup d'espace et est ** plus lente que d'essayer directement des mots de passe **.
@aslum - Je ne dirais même pas "probablement en sécurité" étant donné que la première chose qu'ils font est d'essayer d'enchaîner plusieurs mots du dictionnaire.
@Ramhound "_la première chose qu'ils font est d'essayer d'enchaîner plusieurs mots du dictionnaire._" de quel cracker de mot de passe parlez-vous?
@Ramhound: Eh bien, si vous choisissez simplement des mots peut-être, mais vraiment vous devriez avoir un petit quelque chose de plus là-dedans comme correct & battery & horse & STAPLE42 ... peu importe s'ils le forcent brutalement, ils vont d'abord saisir les mots de passe d'un mot, puis les deux mots , puis les trois. Ce qui va être la grande majorité des utilisateurs. Là encore, peut-être que les hackers sont des complétionnistes, ou sont spécifiquement intéressés par vos mots de passe et qu'ils continueront jusqu'à la mort thermique de l'univers, ou qu'ils déchiffreront votre mot de passe, selon la première éventualité.
Thomas Pornin
2012-10-28 03:22:18 UTC
view on stackexchange narkive permalink

Les sels empêchent le parallélisme. Le parallélisme est générique dans tout le continuum espace-temps; par là, je veux dire qu'il peut être appliqué dans l'espace et dans le temps:

  • Espace- le parallélisme sage , c'est quand l'attaquant a plusieurs hachages à casser (c'est la situation LinkedIn). Avec des hachages non salés, l'attaquant peut hacher un mot de passe potentiel et rechercher le résultat dans la liste complète des hachages qu'il veut casser.

  • Parallélisme temporel c'est quand l'attaquant précalcule les hachages de mots de passe communs, dans une grande table (arc-en-ciel ou non), à appliquer sur les hachages qu'il obtient ultérieurement .

Ce que Ptacek voulait dire, c'est que:

  • Les sels ne font que la moitié du travail; pour vraiment ralentir l'attaquant, vous avez besoin d'un processus de hachage intrinsèquement lent, comme bcrypt.

  • Quand il y en a beaucoup utilisateurs, au moins certains des mots de passe seront si faibles qu'ils seront craqués, quelle que soit la quantité de bcryptness salée que vous faites.

Donc, alors que les sels se seraient quelque peu améliorés la situation pour LinkedIn, ils ne les auraient pas sauvegardés , seulement retardé et quelque peu dilué le problème. L'utilisation de bcrypt ou PBKDF2 aurait encore amélioré les choses, mais pas au point que la violation pourrait être totalement ignorée.

Je ne dirais pas que "le sel empêche le parallélisme". Je préfère dire qu'ils empêchent les attaques multi-cibles.
liviu
2012-06-11 20:00:47 UTC
view on stackexchange narkive permalink

Si un attaquant exploite un système et que le sel est également compromis, la différence est que les tables arc-en-ciel précalculées seront inutiles. (Tout mot de passe particulier peut être stocké de différentes manières, selon la taille du sel). Les tables arc-en-ciel étant un compromis entre le temps et l'espace, il faudrait beaucoup plus d'espace.

J'espère que cela aide. Un exemple est l'utilisation de salt dans le fichier shadow sous UNIX, décrit clairement ici: Pourquoi shadow?

"Les tables arc-en-ciel étant un compromis entre le temps et l'espace, il faudrait beaucoup plus d'espace ._" alors, pourquoi s'embêter avec des tables?
Ramhound
2012-06-11 19:56:48 UTC
view on stackexchange narkive permalink

Ptacek ne dit pas vraiment qu'un sel n'aurait pas empêché les mots de passe LinkedIn d'être piratés. J'aurais à dire que selon la taille du sel, il aurait même protégé le pire des mots de passe.

La seule faiblesse SHA1 est sa faiblesse face à une attaque par force brute. Tout ce que vous avez à faire est de générer des hachages X à l'avance et de comparer la valeur du hachage SHA1 d'une chaîne à votre liste de hachages générée.

Avec un sel en fonction de la taille afin de générer la liste à l'avance de temps prendrait un temps très long et une très grande quantité de stockage sur disque. Vous devez vous rappeler qu'il faudrait générer la même liste pour chaque sel possible. À ce stade, votre seul espoir est d'essayer chaque combinaison et d'espérer trouver une correspondance. Si vous êtes en mesure de générer un sel unique par utilisateur sans stocker le sel dans une base de données, vous êtes encore plus sûr.

En d'autres termes ... Au lieu que chaque mot de passe soit fissuré ... LinkedIn ne regarderait qu'un très petit pourcentage des mots de passe de leurs utilisateurs divulgués (le pire des pires).

Mise à jour

Où stockeriez-vous la clé?

Si cela était fait correctement, vous n’auriez pas besoin de la stocker. Générez simplement un sel basé sur le nom d'utilisateur, lorsque le compte a été créé, ou une combinaison des deux et vous auriez un sel unique pour l'utilisateur donné.

Donc, à moins que la source de votre site Web lui-même ne soit divulguée, aucun pirate informatique ne pourrait la générer. Vous pouvez même rendre cela plus sécurisé et générer un nouveau sel lorsque l'utilisateur a changé le mot de passe du compte.

«Si vous êtes capable de générer un sel unique par utilisateur sans stocker le sel dans une base de données», comment pourriez-vous?
@curiousguy: Vous pouvez calculer le sel à partir du nom d'utilisateur, de la date d'enregistrement ou d'un autre champ de profil immuable, en utilisant un algorithme / clé inconnu de l'attaquant (c'est-à-dire non stocké dans la base de données).
@JesseMcGrew Où stockeriez-vous la clé?
@curiousguy - Voir ma mise à jour.
Je ne comprends toujours pas. Je suppose que vous stockez le nom d'utilisateur et quand le compte a été créé dans la base de données. D'autre part, vous pouvez utiliser l'adresse IP du client comme sel. (Nettoyez vos journaux et supposez que le client a toujours une adresse IP statique.)
Si vous générez le sel à partir de certaines données relatives à l'utilisateur, vous autorisez l'attaquant à attaquer plusieurs instances du hachage (par exemple sur des systèmes séparés) pour le coût d'une attaque. Si vous comptez sur votre code source pour rester secret, vous entrez dans les domaines de la sécurité par l'obscurité.
@Jacco - Il est clair que l'utilisation d'un sel unique résout tous les problèmes, mais cela arrête certainement certains problèmes graves.
"_La seule faiblesse SHA1 est sa faiblesse face à une attaque par force brute._" Ce n'est pas une faiblesse de SHA-1, c'est la faiblesse de ** l'utilisation ** de SHA-1 où la résistance à l'attaque par force brute est requise.
@emory "_ (Frottez vos journaux et supposez que le client a toujours une adresse IP statique.) _" Êtes-vous sérieux?
@curiousguy Dans la grande majorité des cas, je ne vois pas comment vous pouvez utiliser un sel que vous ne stockez pas. Mais si vous ne gardez pas les journaux http et que vous supposez opérationnellement que vos clients auront toujours la même adresse IP (ce qui n'est pas raisonnable), vous pouvez utiliser l'adresse IP du client comme un sel. Sans faire une sorte d'hypothèses déraisonnables, je ne vois pas comment vous pouvez avoir un sel qui n'est pas stocké sur votre système.
@curiousguy: Vous stockeriez la clé dans votre code source ou dans la mémoire partagée. Il ne serait pas à l'abri d'un attaquant disposant d'un accès root, mais il serait à l'abri de celui qui n'a qu'un accès SQL. Ce n'est pas «la sécurité par l'obscurité» - toute cryptographie repose sur la capacité de garder une valeur secrète.
Pour clarifier, je parle d'une fonction du type: salt = hash (combine (nom d'utilisateur, date de création, clé secrète)). L'algorithme n'est pas secret, mais la clé l'est.
@JesseMcGrew Je comprends que la menace qui vous préoccupe le plus est l'injection SQL, est-ce exact? Je pense que l'injection SQL est très facile à éviter d'utiliser la bonne approche (ne pas coller les chaînes ensemble aux requêtes SQL construites). Si vous avez une clé secrète quelque part, vous pouvez même crypter toutes les données de la base de données, pas seulement les mots de passe (sauf pour les index autres que les index hachés, bien sûr). Ou vous pouvez crypter les fichiers de la base de données ou le périphérique de stockage de masse de la base de données.
@curiousguy La menace qui me préoccupe est tous les cas où un attaquant accède à la base de données (comme cela s'est apparemment produit sur LinkedIn), sans avoir accès au code source de l'application ou à la mémoire partagée. L'injection SQL n'est que l'une des nombreuses façons possibles. Bon point sur le chiffrement du reste du contenu de la base de données.
@JesseMcGrew "_comme apparemment arrivé sur LinkedIn_" "apparemment" en effet: tant que nous ne savons pas comment la base de données a été accédée, nous ne pouvons pas exclure un accès à distance au dispositif de vérification des mots de passe en cours d'exécution (avec les clés de cryptage et tout). Mais il est plausible qu'ils n'aient eu accès qu'à une copie de sauvegarde récente de la base de données (les sauvegardes IMO doivent toujours être chiffrées).
@JesseMcGrew - Même si vous deviez stocker le sel unique pour chacun de vos utilisateurs et que toute la base de données a été volée. Vous seriez mieux si vous utilisiez un seul sel. C'est la raison pour laquelle je suggère d'utiliser un sel unique qui peut être généré en fonction du profil de l'utilisateur. Même si la capacité de générer le sel était compromise, vous seriez toujours mieux lotis si vous aviez utilisé un seul sel pour tous vos utilisateurs.
@curiousguy - En effet. La génération de sel à partir du profil de l'utilisateur offre une protection supplémentaire contre l'injection SQL, le vol de sauvegarde ou l'effraction dans un serveur de base de données ... et comme le souligne Ramhound, même si le serveur d'applications est également piraté, vous n'êtes toujours pas pire qu'avec sel traditionnel par utilisateur.
@JesseMcGrew Si vous avez accès à la base de données en cours d'exécution ou à une copie de sauvegarde, ou si vous pouvez faire une injection SQL, vous avez accès à tous les "profils utilisateurs".
@curiousguy - Correct, mais sans accès au code source, vous ne connaissez pas la clé secrète qui est hachée avec les données de profil pour générer le sel.
Notez qu'un composant "secret" dans le hachage de mot de passe (en tant que clé spécifique à votre serveur) n'est souvent pas appelé sel, mais * pepper * (un sel n'est pas considéré comme secret).
@JesseMcGrew "_sans accès au code source_" ce qui signifie que vous avez l'intention de garder le secret source, ce qui implique que le logiciel n'est jamais distribué, en tant que source ou ou en tant que binaire (un binaire peut être rétro-ingénierie). C'est une exigence très forte: cela signifie que le code source ne peut pas être largement examiné par les pairs, ce qui est souvent considéré comme mauvais, en particulier pour le code subtil et sensible à la sécurité.
@curiousguy: Vous pouvez biffer la clé avant d'envoyer le code pour révision, ce qui est facile si vous la conservez dans un fichier séparé. Ou vous pouvez supprimer complètement la clé du code source en la plaçant dans la mémoire partagée ou dans un référentiel au niveau du système d'exploitation. Ce genre de chose est généralement effectué par des applications qui traitent des secrets, tels que des clés pour la signature d'assembly dans .NET ou des secrets partagés pour interagir avec des systèmes tiers.
@JesseMcGrew Si la révision du code peut être effectuée sans regarder quelque chose, alors par définition ce quelque chose n'est pas du code source.
@curiousguy Je ne suis pas d'accord - une déclaration de variable est du code source, mais la valeur utilisée pour initialiser la variable n'est pas nécessaire pour une révision de code - mais peut-être seriez-vous plus satisfait du terme «ressource».
@JesseMcGrew "_Je ne suis pas d'accord_" J'ai écrit "par définition", donc vous n'êtes pas d'accord avec au moins une définition possible du "code source": "ce qui est examiné par la revue de source". Une autre définition différente et incompatible du "code source" est "* .c, * .cc, * .cpp, * .h, * .hh, * .hpp, etc." Quoi qu'il en soit ... ce qui compte, c'est que nous nous entendions sur une définition pour le plaisir de la discussion, et que nous reconnaissions qu'il existe plus d'une définition.
bobobobo
2013-04-15 01:27:40 UTC
view on stackexchange narkive permalink

Une personne avec les tables de base de données volées n'a que 2 champs par utilisateur. 

  password hash saltc32528b3e9191a8c7471252c6de289939a1e6f01 cGFzc3dvcmQ

Dans les termes les plus élémentaires, le chemin Je comprends cela, tout ce que fait le salage, c'est allonger le mot de passe .

Le mot de passe d'origine était "password". Mais j'ai ajouté au mot de passe avant de calculer le hachage le sel cGFzc3dvcmQ pour faire passwordcGFzc3dvcmQ . Qu'est-ce que cela fait? Eh bien, cela le rend juste si vous avez une table arc-en-ciel de mots de passe communs et de leurs hachages, 

  mot de passe hashpassword 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

où vous pouvez voir en un coup d'œil que SHA ('password') = 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 , la recherche du mot de passe d'origine à partir du hachage est trop simple. Nous voulons que le cracker doive faire un peu de travail pour cela.

Alors nous allons "Dyoh! Nous avons ajouté ou ajouté CETTE CHAINE ALÉATOIRE ICI au mot de passe d'origine! Maintenant, vos tables de hachage de commun les mots de passe et leurs hachages sont inutiles "

Ce qu'ils sont. Parce que nous avons complexifié chaque mot de passe par la chaîne aléatoire, en gros "améliorer les mots de passe de l'utilisateur", et complètement bousiller les hachages pour qu'ils soient complètement rares maintenant.

Donc, le salage le rend si chaque hachage a à craquer individuellement , car pour ce faire, si le cracker a les sels, le cracker doit ajouter / ajouter le sel à chaque mot de passe commun qu'il essaie. 2 utilisateurs différents pourraient utiliser le simple mot de passe password , mais le cracking sera 2 tâches entièrement séparées pour le pirate, à cause du sel. Donc, craquer tous les mots de passe prendra plus de temps.

L ' article ici dit qu'en raison de la puissance de calcul disponible aujourd'hui, cependant, utiliser des sels est facile à craquer.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...