Je discute des noms d'utilisateur comme un moyen de sel de mots de passe, au lieu de stocker une chaîne aléatoire avec les noms. Ma justification est que le but du sel est d'empêcher les tables arc-en-ciel, alors qu'est-ce qui rend cela de manière réaliste moins sécurisée qu'un autre ensemble de données là-bas?
Par exemple,
vs
Y a-t-il une vraie raison pour laquelle je ne pouvais pas simplement coller avec le nom d'utilisateur et simplifier les choses? La seule chose que ma recherche Web a abouti à la recherche de débats sur la manière dont un sel doit être comme un mot de passe, mais s'est terminé sans aucun raisonnement derrière celui-ci, où je suis sous l'impression, il s'agit simplement d'empêcher quelque chose comme un Cain-et-capable de courir contre elle sans être compris entre un million d'années. En pensant au traitement des limitations de la réalité, je ne crois pas que ce soit une grosse affaire si les gens connaissent le hachage, ils ne connaissent toujours pas le mot de passe, et ils sont entrés dans la plage super-ordinateur à la force brute chaque hachage individuel.
Quelqu'un pourrait-il s'il vous plaît éclairer ici? hachage (md5 (johnny_381@example.com), p4ss \ / \ / 0rd)
hachage (MD5 (quelque_uuid_value), P4SS \ / \ / 0RD)
6 Réponses :
Vous rencontrerez des problèmes lorsque le nom d'utilisateur change (si cela peut être modifié). Vous ne pouvez pas mettre à jour le mot de passe haché, car vous ne stockez pas le mot de passe non étailé non négligé.
J'aime cette raison en compliquant ce que fait mon système, mais je ne vois pas pourquoi je ne peux pas exécuter un nouveau jeu de mot de passe à ce moment-là (cela pourrait même être aussi simple que le changement "Vérifier le changement avec votre mot de passe " filtrer).
Vous pouvez également utiliser la date d'enregistrement. Ce n'est pas si susceptible de changer :)
@chris_i: Je suis d'accord avec user257493, s'ils changent le nom d'utilisateur, stockez simplement un mot de passe nouvellement crypté en même temps.
@ user257493 Oui, si vos utilisateurs sont corrects avec cela, et si le sel doit être transmis ouvertement de toute façon, il est presque aussi bon qu'un sel aléatoire. (C'est théoriquement possible que quelqu'un précalcule une table avec des noms d'utilisateur communs.)
@ M01 J'aime beaucoup votre idée, il est beaucoup moins susceptible d'être connu de la durée de microseconde que le bâtiment SQL String a eu lieu sur mon serveur. @chris_i la conception à l'heure actuelle les a à l'heure ouverte, ce qui est quelque peu malheureux (et pourquoi je demande).
@ user257493 Je suis d'accord avec David Thornley, que ça va de les avoir à l'air libre. Le secret est le mot de passe. Essayer d'ajouter une sécurité en caché le sel est un peu obscur de toute façon. J'aime aussi l'idée de M01!
Je ne peux pas croire que cela a eu 9 votes et une réponse correcte. Si les modifications de nom d'utilisateur, je suppose que vous souhaitez que le mot de passe le fasse. Ainsi, vous avez un ancien nom d'utilisateur, nouveau nom d'utilisateur et mot de passe actuel. Valider l'utilisateur, mettre à jour le nom d'utilisateur, le mot de passe de Rehash avec un nouveau hachage.
@theunhandleXception: essayez-le sur Stackoverflow: lorsque le nom d'utilisateur change, il ne nécessite pas de changement de mot de passe. C'est assez habituel, car du point de vue d'un utilisateur, il n'est pas facile de voir pourquoi un changement de mot de passe serait requis dans ce cas. Bien sûr, vous pouvez la mettre en œuvre de cette façon, si vos utilisateurs sont d'accord avec cela (comme je l'ai dit dans un commentaire précédent).
Je ne vois pas de problème avec l'utilisation du nom d'utilisateur comme valeur du sel.
Une manière plus sécurisée de stockage de mots de passe implique d'utiliser une valeur de sel différente pour chaque enregistrement de toute façon.
Si vous regardez la table aspnet_membership du fournisseur d'adhésion ASP.NET, vous verrez qu'ils ont stocké les champs de mot de passe, de mots de passe, et de nom d'utilisateur dans le même enregistrement. Donc, à partir de ce point de vue, il n'y a pas de différence de sécurité en utilisant simplement le nom d'utilisateur pour la valeur de sel.
Notez que certains systèmes utilisent une seule valeur de sel pour tous les mots de passe et stockez cela dans un fichier de configuration. La seule différence de sécurité ici est que si elles ont gagné un accès à une seule valeur de sel, ils peuvent ensuite construire plus facilement une table arc-en-ciel pour craquer tous les mots de passe à la fois ...
mais encore une fois, s'ils ont accès à la forme cryptée des mots de passe, ils auraient probablement accès à la valeur de sel stockée dans la table d'utilisateurs juste avec elle ... ce qui pourrait signifier qu'ils auraient un peu Temps plus difficile de déterminer les valeurs de mot de passe.
Cependant, à la fin de la journée, je crois que presque toutes les applications échouent sur le front de cryptage car elles sont chiffrer ce qui est ostensiblement l'une des données les moins importantes: le mot de passe. Ce qui devrait vraiment être crypté est presque tout le reste.
Après tout, si j'ai accès à votre base de données, pourquoi devrais-je m'intéresser si le mot de passe est crypté? J'ai déjà accès aux choses importantes ...
Il existe évidemment d'autres considérations en jeu, mais à la fin de la journée, je ne transpirais pas trop celui-ci que c'est une question mineure comparé les autres.
Le mot de passe est très important, car de nombreux utilisateurs utilisent le même mot de passe pour plusieurs systèmes!
hachage! = cryptage, hachage est plus service à vos utilisateurs. Depuis que le hachage par définition n'est pas réversible, vous protégeez votre mot de passe de vos utilisateurs de même Possible d'insister Snooping. Le cryptage de l'autre-main ne peut pas protéger de l'orchestre par des initiés avec une clé. Techniquement, si vous ne planifiez pas votre base de données jamais volée, pourquoi ne pas conserver les mots de passe de ClearText?
@Joshperry: Je discutais réellement l'inverse. Vous devriez planer sur votre base de données étant volée, c'est pourquoi le tout doit être crypté, pas seulement les mots de passe.
Chris, les noms d'utilisateur sont entièrement prévisibles, ils seraient donc vulnérables à une table arc-en-ciel générée pour ce nom d'utilisateur.
@Steven: Mais la table arc-en-ciel ne s'appliquerait qu'à celui-ci dans cette base de données. Le but d'un sel est d'empêcher les tables arc-en-ciel d'être appliquées à tous les enregistrements. En effet, une table arc-en-ciel devrait être compilée pour chaque nom d'utilisateur. Ceci n'est tout simplement pas réalisable car vous parlez de générer entre 8 Go et 80 Go de données arc-en-ciel par nom de connexion. Le temps qu'il faudrait pour le faire est non-trivial et monte avec la longueur du mot de passe.
@Chris: Vous êtes un gars sympa, mais vous n'avez pas d'esprit criminel. Vous n'avez besoin que de pirater un compte, qui a un nom prévisible: administrateur.
@Josh: Bon point. En fait, la plus grande vulnérabilité de l'utilisateur est qu'ils continuent à transmettre leur mot de passe. Si le système leur envoie leur sel, ils peuvent faire le hachage du côté du client et envoyer uniquement le haché sur le fil.
@Steven: fourni "Administrator" est un nom d'utilisateur réel de votre système, puis je suis d'accord ... Concernant l'idée de passer uniquement la version hachée, cela n'est vraiment plus sûr que de passer le mot de passe "plain" pour le côté serveur de hachage. Soit est vulnérable à la relecture.
@Chris: Le stockage de la hachage salée empêche un initié de déterminer les mots de passe des utilisateurs, mais cela ne les empêche pas de subvertir le processus de connexion pour enregistrer le mot de passe avant le hachage. D'autre part, si nous donnons le sel et une nonce au client, demandez à l'utilisateur de saisir leur mot de passe, de hachage avec le sel, puis de hachage avec le nonce utilisant HMAC ...
Cette méthode a été jugée suffisamment sécurisée pour le groupe de travail créé une authentification HTTP Digest, qui fonctionne avec un hachage de la chaîne "Nom d'utilisateur: royaume: mot de passe".
Je pense que vous allez bien voir car cette décision est secrète. Si quelqu'un vole votre base de données et votre code source pour voir comment vous avez réellement mis en œuvre votre hachage, bien ce qu'elles se connectent pour accéder à ce point? Le site Web qui affiche les données de la base de données qu'ils ont déjà volée?
Dans ce cas, un sel achète votre utilisateur quelques avantages de sécurité. Premièrement, si le voleur a des valeurs précalisées (tables arc-en-ciel), ils devraient les recomposer pour chaque utilisateur afin de faire leur attaque; Si le voleur est après le mot de passe d'un seul utilisateur, ce n'est pas une grosse victoire.
Deuxièmement, les hachages pour tous les utilisateurs seront toujours différents même si elles partagent le même mot de passe, le voleur n'obtiendrait pas de collisions de hasch gratuitement (crack One utilisateur obtient 300 mots de passe).
Ces deux avantages aident à protéger vos utilisateurs qui peuvent utiliser le même mot de passe sur plusieurs sites, même si le voleur arrive à acquérir les bases de données d'autres sites.
Ainsi, alors qu'un sel pour le hachage de mot de passe est mieux gardé secrète (qui dans votre cas, les données exactes utilisées pour le sel seraient), cela fournit toujours des avantages même s'il est compromis.
Le salage aléatoire empêche la comparaison de deux hachages de mot de passe de manière indépendante pour le même nom d'utilisateur. Sans cela, il serait possible de vérifier si le mot de passe d'une personne sur une machine correspondait à celui d'une autre, ou si un mot de passe correspondait à celui utilisé dans le passé, etc., sans avoir à avoir le mot de passe réel. Il faciliterait également considérablement la recherche de critères tels que ceux ci-dessus, même lorsque le mot de passe est disponible (car on pourrait rechercher le hachage calculé, plutôt que de calculer le hachage séparément pour chaque vieille valeur hachage de mot de passe).
quant à savoir si une telle prévention est une bonne chose ou une mauvaise chose, qui sait.
C'est pourquoi tout sel dérivé doit être renforcé via PBKDF2. L'utilisation d'un nombre personnalisé d'itérations et de sel de site personnalisé rendra vos «sels de nom d'utilisateur» uniques à votre site.
Si vous utilisez le nom d'utilisateur comme mot de passe et que vous trouverez de nombreuses instances de votre application, les personnes peuvent créer des tables arc-en-ciel pour des utilisateurs spécifiques tels que "admin" ou "système", comme si c'est le cas avec des bases de données Oracle ou avec une liste complète de commune Les noms comme ils l'ont fait pour WPA (COWPATTY)
Vous feriez mieux de prendre un sel vraiment aléatoire, ce n'est pas si difficile et il ne reviendra pas de vous hanter.
PBKDF2 fournit une protection contre une table de recherche. Bien que votre site puisse avoir des noms d'utilisateur "connus", vous avez deux autres éléments. Le sel statique sur la fonction PBKDF2 et le nombre d'itérations. Ainsi, "admin" sur mon site générera un sel dérivé totalement différent de "admin" sur votre site.
Je sais que c'est une ancienne question, mais pour toute personne recherchant une solution basée sur cette question.
Si vous utilisez un sel dérivé (par opposition au sel aléatoire), la source de sel doit être renforcée en utilisant une fonction de dérivation de clé comme PBKDF2.
Ainsi, si votre nom d'utilisateur est "TheUnhandleXception", passez via PBKDF2 pour x itérations pour générer un 32 bit (ou quel que soit le sel de longueur dont vous avez besoin).
Faites x pseudo aléatoire (par opposition à des nombres même comme 1 000) et transmettez-le dans un site statique spécifique au sel spécifique au PBKDF2 et que vous le rendez hautement improbable que votre sel d'utilisateur correspondre à tout sel d'utilisateur.
J'ai trouvé un excellent article connexe. web.archive.org/web/20080822090959/http://www.matasano.com/l og / ...