Disons que j'ai une table d'utilisateurs configurée comme ceci: Lorsqu'un utilisateur est créé, un sel généré au hasard est produit et stocké dans la base de données à côté des résultats de quelque chose Comme Je me demande que si un utilisateur malveillant a la main sur ces données, serait-il en mesure de l'utiliser pour craquer les mots de passe des utilisateurs? Si oui, qu'est-ce que cela pourrait être empêché? P> p> get_hash (sel + plainteext_password) code>. p>
7 Réponses :
Si un attaquant connaît le sel, le mot de passe haché et l'algorithme de hachage, ils peuvent ensuite monter une attaque de dictionnaire de force brute (ou une attaque arc-en-ciel). P>
Les sels gagnent leur pouvoir en étant uniques à l'entrée, pas en étant secrets. Vérifiez l'entrée Wikipedia sur la table arc-en-ciel où elle est indiquée "Un sel est souvent utilisé avec des mots de passe hachés pour rendre cette attaque plus difficile, souvent infaisable".
Non, ils ne sont pas inutiles. P>
Tant que vous utilisez un sel unique pour chaque rangée, le sel Comme mentionné dans les commentaires, vous devez vous assurer que le sel est une taille sensible. P>
La question demande si l'attaquant connaît le sel
La réponse de Luke suppose que l'attaquant connaisse le sel. Le point est que sans sel du tout, l'attaquant pouvait simplement rechercher le mot de passe haché dans une table arc-en-ciel dans le filet. Avec l'ajout du sel, l'attaquant doit faire la force brute fonctionner eux-mêmes.
Point crucial: la taille du sel doit être choisi assez grande que l'attaquant ne peut pas avoir de table arc-en-ciel suffisamment grande. Évidemment, 8 morceaux de sel n'empêcheraient pas absolument une attaque de table arc-en-ciel, augmente simplement la taille de la table requise par rapport à 256. 128 bits de sel aléatoire, OTOH, règle des tables arc-en-ciel maintenant et pour toujours.
@Mitch: Précomptable Toutes les hachages MD5 possibles (pour donner un exemple non sécurisé) de mots de passe jusqu'à N caractères sont faciles. La salage est bonne car de préconformer que de nombreux mots de passe * Nombre de sels possibles ne sont pas possibles. Le sel n'est pas caché.
Connaître le sel permet de faire une attaque de force brute, mais cela ne le rend pas inutile. Le sel empêche l'attaquant d'utiliser une table arc-en-ciel déjà générée (que vous pourriez trouver sur le Web). P>
Le meilleur moyen d'empêcher la forçage brute est simplement d'utiliser des mots de passe longs et complexes. P>
Salting a été introduit (ou au moins rendu populaire) dans un fichier Unix / etc / passwd, qui était lisible dans le monde entier. On suppose généralement que le sel ainsi que le mot de passe crypté est connu du cracker. Le but du sel est le ralentissement du processus de craquage (puisque le même mot de passe ne correspond pas à la même chaîne cryptée); Il est pas em> secret en soi. P>
Non, ce n'est pas sans valeur. p>
Pour attaquer avec succès un compte, un attaquant doit connaître le sel pour ce compte (et le sel de chaque compte devrait être différent), l'algoright hachage utilisé, et em> le cas de mot de passe final stocké. p>
donné tous em> de ces informations, vous pouvez écrire un programme qui empêche d'essayer de récupérer des mots de passe potentiels différents jusqu'à ce qu'il en trouve une correspondance. p>
Si c'est un Bad em> sel (trop simple ou court), cela peut être réalisé beaucoup plus rapidement car le programme peut utiliser des tables de recherche Rainbow pour correspondre au hachage de mot de passe stocké final à la chaîne hachée, puis soustrayez le sel. Mais ils ont encore besoin de toutes les informations. P>
Si c'est un sel partagé em>, c'est mauvais, car un attaquant et utilisez le sel pour générer une table arc-en-ciel à l'avance, c'est bon pour tout compte sur votre système. P>
Cela devrait vous donner une idée de la façon dont cela fonctionne. P>
permet de dire que vous voulez crypter un mot "secret". Après qu'il est crypté, disons que cela ressemble maintenant à ce 00110010. P>
Si un pirate informatique connaît l'algorithme de cryptage, ils peuvent créer une table de mots et leurs valeurs cryptées correspondantes. Donc, ils prennent le mot de passe crypté "00110010" et trouvez-le dans la table. Maintenant, ils savent que le mot de passe utilisé pour générer "00110010" était le mot "secret". Si vous salez le mot en premier, une table de recherche générique sera inutile pour le pirate informatique. (Une table de recherche générique étant une table de mots de dictionnaire non salé et de leurs valeurs cryptées) p>
Si vous salez le mot en premier ("saltsecret"), la valeur cryptée sera maintenant différente et le pirate informatique ne le trouvera pas dans la table de recherche. P>
Cependant, ils peuvent toujours commencer à créer leur propre table de recherche à partir de zéro à l'aide de votre sel et, éventuellement, ils seront en mesure d'inverser les mots de passe de recherche. p>
Donc, pour répondre à la question, si les mots de passe sont suffisamment complexes, il prendra des âges pour le pirate informatique pour les comprendre. Vous pouvez changer votre sel chaque année et ils devraient commencer à créer une table de nouveau. P>
De plus, si vous n'utilisez pas de sel (ou si vous utilisez un sel partagé), l'attaquant saura que chaque rangée avec le hachage "00110010" a le mot de passe "secret". Si vous utilisez un sel unique pour chaque ligne, chaque utilisateur pourrait avoir le même mot de passe et que l'attaquant ne le saurait pas.
En supposant que l'attaque de la force brute de MD5, SHA1, algorithmes SHA256 avec GPU a un débit supérieur à 1 milliard d'essais par seconde et SHA512 environ 300m / s. Si vous utilisez l'un de ces algorithmes, il ralentira le pirate informatique qui a utilisé une table arc-en-ciel (moins probable), mais cela ne ralentira pas le pirate informatique qui a utilisé une attaque de force brute (plus probable). Il ne vous protégera définitivement pas, il s'agit simplement d'ajouter un peu de sécurité contre la table arc-en-ciel obsolète (pour ces algo). Un peu mieux que rien. P>
Mais si vous utilisez un algorithme le plus fort (par exemple, BCRYPT), sel en vaut définitivement la peine, même s'il est stocké avec un hachage car la force brut n'est pas réalisable en termes de délai d'arc-en-ciel. P>
Regardez cette Article et résumer: P>
Si vous êtes un utilisateur: p>
Assurez-vous que tous vos mots de passe sont de 12 caractères ou plus, idéalement beaucoup plus. Je recommande d'adopter des phrases de passe, qui ne sont pas seulement beaucoup plus faciles à retenir que les mots de passe (si ce type), mais aussi de manière ridiculement sécurisée contre la brute forçante purement due à leur longueur. P>
Si vous êtes un développeur: p>
Utilisez BCRYPT ou PBKDF2 exclusivement à HASH tout ce que vous devez être sécurisé. Ces nouveaux hachages ont été spécialement conçus pour être difficiles à mettre en œuvre sur GPU. N'utilisez aucune autre forme de hachage. Presque tous les autres systèmes de hachage populaire sont vulnérables à la forçage brute par des tableaux de GPU sur les produits de base, qui ne sont plus rapides et plus parallèles et plus faciles à programmer pour chaque année. P>
Publié par Jeff Atwood P> blockQuote>