Comment puis-je mettre en œuvre le sel dans mon login pour les mots de passe?

Je veux mettre en œuvre un sel dans mon système de connexion mais je suis un peu confus sur la façon dont cela est censé fonctionner. Je ne comprends pas la logique derrière elle. Je comprends md5 est un algorithme et toutes les fonctions que j'ai rencontré semblent pour hacher le tout. Si c'est le cas, comment peut-on obtenir le mot de passe de retour pour la comparaison? Ma grande question est, comment est-saler un des utilisateurs de mot de passe plus sûr que juste le hachage du mot de passe? Si une base de données n'a jamais été compromise, le hachage, ainsi que le sel est à la base de données. N'est-ce pas tout ce qu'un hacker aurait besoin?

J'ai aussi trouvé un autre post ici sur ALORS, où un autre développeur a dit :

"Assurer votre sel et de l'algorithme sont
stockées séparément de la base de données"

Je voudrais stocker le sel dans la base de données. Est-ce vraiment un problème si je le fais?

Je suis à la recherche d'un peu d'aide pour comprendre comment cela fonctionne et quelles sont les meilleures pratiques pourrait être. Toute aide est grandement appréciée.

EDIT:
Je tiens à remercier tout le monde pour leurs réponses et les idées. Même si j'ai peut-être plus confus maintenant, il a certainement été une expérience d'apprentissage pour moi. Merci encore les gars.

Bienvenue DONC. Grande première question.
stackoverflow.com/questions/873403/net-impl-of-bcrypt
Liés à lire: L'arc-en-ciel de la Table Est Mort

InformationsquelleAutor Timmay | 2010-02-02

18

Une fonction de hachage retourne toujours la même valeur pour la même chaîne d'entrée. Disons que mon utilisateur (Alice) a le mot de passe secret. Le hachage secret à l'aide de md5() conduit à la suite de hachage
```
5ebe2294ecd0e0f08eab7690d2a6ee69
```
À l'aide d'un dictionnaire (une liste de mots courants et mot de passe) ou l'un des différents sites que vous offrir ce service, l'attaquant (Mallory) peut facilement trouver le mot de passe est secret lorsqu'il voit dans son dictionnaire de 5ebe2294ecd0e0f08eab7690d2a6ee69 = secret.

Le processus de salage avant le hachage rend plus difficile d'utiliser une attaque par dictionnaire sans connaître votre sel. Considérez les points suivants:
```
<?php
$salt = '@!#%$@#$@SADLkwod,sdaDwqksjaoidjwq@#@!';
$hash = md5($salt . 'secret');
```
L'résultant de hachage est maintenant b58ad809eece17322de5024d79299f8a mais Alice mot de passe est toujours secret. Maintenant, si Mallory obtient ses mains sur le salé de hachage, les chances sont qu'elle ne va pas trouver la réponse dans son dictionnaire. Si elle le fait, le dictionnaire lui donner la mauvaise réponse.

Ne jamais stocker une statique de sel dans votre base de données. De préférence, les stocker avec votre configuration de l'application (qui d'ailleurs ne devrait pas être disponible sur le web).

Si vous allez utiliser une dynamique de sel, vous allez avoir besoin d'utiliser la base de données. Utiliser une valeur non nulle de la colonne de l'existant valide les données de votre sel (blowfish-chaîne cryptée de nom d'utilisateur basée sur un secret de la clé de chiffrement est généralement cryptographique sécurisé). Ne pas utiliser une colonne séparée pour le sel. Si vous ne pouvez pas utiliser une colonne existante, incorporer le sel dans la même colonne que votre hash. Par exemple, utiliser les 32 premiers caractères de votre 128-bits de sel, puis les 40 dernières pour votre 160 bits de hachage. La fonction suivante va générer un tel hash:
```
function seeded_sha1($string, $seed_bits) {
    if(($seed_bits % 8) != 0) {
        throw new Exception('bits must be divisible by 8');
    }

    $salt = '';
    for($i = 0; $i < $seed_bits; $i+=8) {
        $salt .= pack('c', mt_rand());
    }

    $hexsalt = unpack('h*hex', $salt);

    return $hexsalt['hex'] . sha1($salt . $string);
}

function compare_seeded_sha1($plain, $hash) {
    $sha1 = substr($hash, -40);
    $salt = pack('h*', substr($hash, 0, -40));

    $plain_hash = sha1($salt . $plain);
    return ($plain_hash == $sha1);
}
```
Si un intrus pénètre dans votre base de données en utilisant SQL injection, au moins les hachages il/elle récupère ne sera pas utile car il/elle n'aura pas accès à la configuration de votre application. Si votre serveur est enracinée, c'est assez beaucoup de jeu sur n'importe ce que vous faites.

Remarque: Il existe d'autres types d'attaques possibles sur md5() qui est pourquoi vous utilisez le plus sûr algorithme de hachage, sha1() par exemple. Ou, mieux encore, utiliser la Portable PHP cadre de hachage de mot de passe, qui a été conçu avec la sécurité à l'esprit et est rétro-compatible avec pratiquement n'importe quel version de PHP.
```
require('PasswordHash.php');

$pwdHasher = new PasswordHash(8, FALSE);

//$hash is what you would store in your database
$hash = $pwdHasher->HashPassword( $password );

//$hash would be the $hashed stored in your database for this user
$checked = $pwdHasher->CheckPassword($password, $hash);
if ($checked) {
    echo 'password correct';
} else {
    echo 'wrong credentials';
}
```
- Fantastique, explication Andrew. Merci. Ne pas aller n'importe où. Je veux vous poser quelques questions après que j'ai fini de lire le reste de votre post.
- Voir chargen.matasano.com/chargen/2007/9/7/... pourquoi SHA-1 (ou SHA-2, ou n'importe quoi d'autre) pas "plus sécurisé algorithme de hachage", pour le hachage de mot de passe.
- Ok, voici ce qui est vissage moi... tout le monde est à dire de générer un aléatoire sel et de le stocker dans la base de données. Semble juste pour moi. Mais, ce que je suis la compréhension de votre message, c'est que je dois pas magasin le hachage dans la base de données, mais au lieu de cela, dans l'application. Si je stocker le sel dans l'application, il ne parvient pas à être dynamique à ce point. Pouvez-vous voir ma confusion?
- La même approche pourrait être pris avec bcrypt. Les dictionnaires n'existe pas pour elle aussi. Ils sont un peu moins disponible. Je suis désolé de le dire, des dictionnaires est une faiblesse qu'aucun algorithme de hachage peut résoudre. Si je ne peux pas casser votre bcrypt de hachage assez de temps avec une machine, je vais obtenir un cluster. Si il n'est toujours pas assez rapide, je vais louer un bot net. Et vous ne savez pas combien de temps nous allons être en mesure de hachage une bcrypt de hachage dans un an. Sa supposée de la sécurité à travers la lenteur est déjà cassé, j'ai peur.
- Non, la sécurité grâce à la lenteur est le meilleur moyen de défense que vous avez; vous avez à ralentir le brute force cracking autant que vous le pouvez. Si tu dis que c'est pas de la défense, alors que c'est équivalent à dire que tout le cryptage est inutile de trop, parce que les gens peuvent brute-force. 😛
- avoir une dynamique de sel qu'un ralentissement de votre attaquant. Si vous voulez toujours avoir une dynamique de sel, de ne pas se rendre évidente de votre agresseur et l'utilisation d'un champ dans votre ligne qui est NON-NULLE pour construire votre sel. La pire chose que vous pouvez faire est d'avoir un champ avec apparemment aléatoires qui ou pire, un champ appelé salt.
- La journée d'une fonction de hachage prend plus de 2 secondes pour calculer, je vais y réfléchir en sécurité sur ce compte. Jusqu'alors, je peux juste paralléliser ma brute-forcer autant que je veux obtenir la réponse que je veux rapidement.
- Je travaille pour l'état de faire une demande et ont dû utiliser leurs ordinateurs et réseaux. Ils avaient une très sécurisé algorithme de mot de passe pour verrouiller les mots de passe. Pas de mots du dictionnaire, 2 lettres majuscules 3 numéros de 16 caractères qui devaient être changées tous les 20 jours. Je courais à travers le bureau à la recherche pour les numéros de série hors du HP imprimantes à utiliser.
- De toute évidence, vous n'avez pas de lire sur bcrypt, alors. bcrypt de gagner est que c'est accordable. Pour le moment, si vous utilisez, disons, 12 journal-tours, vous pouvez plus tard jusqu'à, disons, 15 journal-tours. Chaque extra journal-ronde double la quantité de tours utilisés pour le calcul d'un mot de passe de l'essai. Et je suis prêt à parier qu'en ce moment, un 15-journal-ronde sel prendra beaucoup plus de temps de 2 secondes pour essayer.
- Ce qui est plus sécurisé? Un hasard de sel ou statique de sel? Si vous dites statiques, alors que c'est la façon dont je vais y aller. Recommanderiez-vous bcrypt?
- -1: Mauvaise réponse. La façon correcte d'utiliser un sel est à la génération aléatoire de sel pour chaque utilisateur et de les stocker dans la base de données. En essayant de les garder à part ou masquer le nom du champ est d'amateur non-sens. Et à l'aide d'un artificiellement ralentir fonction de hachage est très bien accepté de bonne pratique.
- L'utilisation aléatoire de sel. Vous (un peu) d'accroître la sécurité de cette manière, pour la plupart des algorithmes. Dans le cas spécifique de bcrypt, le nombre de journaux-tours utilisé est codé dans le sel à l'aide d'un sel pour chaque mot de passe, vous pouvez progressivement mise à niveau de plus en plus forte de hachage.
- Édité ma réponse à ce que je voulais à l'origine. Pour la dynamique des sels, vous n'avez besoin de le stocker dans la base de données, mais ne pas ajouter un champ pour elle. L'utilisation d'un champ existant de données valides, et de chiffrer sur la base d'un statique privée de la clé secrète. Qui permettra d'obtenir un niveau de chiffrement secure hash.
- Je ne prétends pas être un expert et c'est pourquoi je suis ici, mais il me semble que si j'avais une clé statique (sel) et j'ai été la SEULE personne dans le contrôle de sel puis un hacker ne serait pas capable de craquer les mots de passe hachés. Je veux dire, il semble logique pour moi de toute façon. Pourriez-vous expliquer comment stocker un hasard sel est plus sûr que la statique de sel?
- Si le sel devient connu, il est facile de reconstruire un dictionnaire que vous avez seulement un à construire. Avoir une dynamique de sel rend plus difficile que vous avez besoin pour construire X dictionnaires, un pour chaque ligne.
- Le risque est que votre attaquant peut accéder à tous du code de votre site ainsi que tous les tables dans la base de données. Si vous pensez à la sécurité de l'un "scénario du pire" point de vue, alors que vous avez tout couvert (comme bien que possible, de toute façon).
- Qu'entendez-vous par magasin de la dynamique de sel dans "un champ de données valides"? Dois-je conserver le sel à-dire, l'adresse e-mail ou nom d'utilisateur? Aussi... Vous êtes en train de parler à l'aide d'une statique de la clé privée. Est-il un extrait de code pour que je puisse regarder de sorte que peut-être je peux le comprendre un peu plus? Certes, je suis plus perdu maintenant que quand je suis arrivé ici. 🙂
- Si vous utilisez bcrypt, le sel est stocké avec le mot de passe haché. La bibliothèque prend soin de tout cela pour vous automatiquement.
- Bouffon-Jeunes vous ne pouvez pas utiliser aléatoire sel, comment yould vous de vérifier pour d'utilisateur mot de passe, si vous ne disposez pas de la dernière génération aléatoire de sel?
- Non, mais vous pouvez utiliser, disons, une version chiffrée de l'adresse e-mail. De cette façon, vous êtes à l'aide de données existantes, mais il n'est pas évident lors de la recherche à la disposition de table.
- Borgwardt vous n'avez pas à générer unique de sels pour chaque utilisateur, il suffit d'utiliser déjà accessibles en colonnes comme je l'ai indiqué dans ma réponse stackoverflow.com/questions/2188507/...
- Le hasard le sel est stocké (en clair) avec le mot de passe haché. Le sel n'a pas vraiment besoin d'être gardé secret, si elle est unique par mot de passe.
- La sécurité par l'obscurité ne vous aide pas. Supposons que votre attaquant pouvez télécharger une copie complète de votre code source, puis de décider si l'utilisation de "crypté adresse e-mail" est mieux que juste le stockage aléatoire de sel dans le clair avec votre mot de passe haché.
- Comme je l'ai dit, une fois que vous êtes enraciné, c'est assez beaucoup plus de jeu. Mais avoir accès au code source, je pense à un tas de moyen plus facile d'obtenir l'accès au mot de passe, avec un retour plus rapide que le traitement de hachages. Si le hash n'est pas apparente dans la base de données, il sera beaucoup plus difficile pour un attaquant ayant accès à la base de données uniquement.
- Mais pourquoi utiliser un autre sel, si vous avez déjà persistante, ne pas changer de colonnes, vous pouvez utiliser un sel avec la combinaison de la statique de sel?
- Qui prend tout son sens pour moi aussi.
- Il existe des moyens pour obtenir une application web de code source qui ne fait pas intervenir de plein "game-over" accès à la racine, ou même d'accéder à la modification dudit code (ce qui serait, comme vous le dites, admettre beaucoup plus facile attaques comme la journalisation de tous les mots de passe entrés).
- regarde ma réponse pour une explication re "clé statique". @juraj: a généré de sel a l'avantage que vous pouvez vous assurer de sa longueur et de la qualité plus facilement et il vous évite d'avoir à expliquer au client qu'il est impossible de modifier certains champs parce que votre concept de sécurité dépend d'eux en cours de correction.
- si vous avez accès au code source (de la racine ou de tout autre type), il est assez totally jeu plus, à partir du code source, vous pouvez étudier toutes les injections et les pannes que vous pouvez effectuer, que DB reste assez protégés 🙂
- Mal. Logiciel sécurisé ne dépend pas de la confidentialité de son code source pour sa sécurité. Sa sécurité est d'être bien codé en premier lieu. Vous savez, les gens peuvent la rétro-ingénierie, tous les aspects d'une source de produits; où pensez-vous que tous les avis de sécurité Microsoft viennent de? (Astuce: IDA Pro.)
- l'ingénierie inverse d'une simple tâche de l'utilisateur de connexion/déconnexion, qui est réalisée sur le côté serveur est à peu près impossible (comme vous l'avez dit, si bien codé).. hovewer obtenir les infos de l'utilisateur, avec l'aide de compromis code source est beaucoup plus facile.. pour résumer, je pense que ce commentaire est assez long et il commence à être controversé:-D
- J'ai commenté dans votre post ci-dessous, en vous demandant votre avis sur la façon dont vous pourriez aller sur le verrouillage de mot de passe s'il ne tenait qu'à vous. J'aimerais partir d'ici avec quelque chose. 🙂
- -1 pour "ne Jamais entreposer le sel dans votre base de données." Il n'y a aucune raison de ne pas stocker les sels dans la base de données; toutefois, ils devraient être unique pour chaque utilisateur ou c'est inutile. Et bien sûr, il n'y a pas de problème avec l'aide d'une base de données unique-champ pour les sels, puisque la le sel n'est pas considéré comme un secret.
- Manifestement, vous arrêter de lire dans le milieu de l'après. Et tandis que le sel n'est pas considéré comme un secret, si seulement votre base de données est compromise, en basant votre sel sur un champ existant considérablement nuire à la capacité d'un attaquant pour être en mesure d'accéder à un compte en particulier. Si le sel est clair dans la base de données et l'attaquant ne s'intéresse qu'à un compte en particulier, il est beaucoup plus facile pour lui de construire un dictionnaire pour essayer et trouver le mot de passe (si ce que ledit mot de passe n'est pas sécurisé).
- "de baser votre sel sur un champ existant considérablement nuire à la capacité d'un attaquant pour être en mesure d'accéder à un compte en particulier" - maintenant, pourquoi dans le monde, pensez-vous que? J'espère que vous n'allez pas dire qu'il est "sécurité par l'obscurité"? 🙂
- Supposons que l'attaquant a accès uniquement à votre base de données. Si vous basez votre sel sur une blowfish-version cryptée de votre adresse e-mail (par exemple), l'attaquant le plus absolument aucun moyen de trouver le sel et ne peut pas construire un dictionnaire pour un compte en particulier. Il n'a pas votre clé, et il n'ont même pas la méthode de chiffrement utilisée. Simplement à l'aide d'un champ, tel qu'il est n'ont pas de valeur depuis sa "sécurité par l'obscurité", mais l'application d'une opération (telles que le cryptage) n'empêche un attaquant avec seulement DB accès de faire n'importe quoi avec vos tables de hachage.
- Chris Bouffon-Jeunes a été correct sur chaque point de mesure.
- Incroyable de discussion, et très informer. Merci à tous. Et il devrait y avoir un badge pour avoir le première question monter en flèche jusqu'ici. 🙂
- C'est à côté de la question. Les gens d'ingénierie inverse parce qu'ils ont accès à des fichiers binaires. Lorsque vous n'avez pas l'accès ni la source, ni les fichiers binaires, vous serez d'accord que le reverse-engineering devient beaucoup plus difficile (pas impossible, plus difficile).
- -1 pour "Utiliser une valeur non nulle de la colonne de l'existant valide les données de votre sel". Cela permettrait d'attacher le mot de passe crypté pour certains autres données, ce qui est mauvais. Utiliser un générateur de nombre aléatoire pour générer le sel pour chaque mot de passe. Ou utiliser une bibliothèque qui ne salage et de hachage pour vous et stocker toutes ses données, y compris le sel comme le hachage de mot de passe.
- Dernier code-exemple est copié à partir de: stackoverflow.com/questions/1581610/...
- Dernier exemple de code est copié à partir du PHP Hachage de Mot de passe de la Documentation. Veuillez obtenir vos références droite.
- Moore: alors s'il vous plaît lien vers l'URL contenant ce code-exemple et je serai corrigé. (Google ne peut pas trouver et je me souviens très clairement écrit exactement cet exemple.)
- Voir test.php de l'0.1 distribution de phppass.
- Moore: Toutes les révisions de test.php sont ici: cvsweb.openwall.com/cgi/cvsweb.cgi/projects/phpass Le code-block n'est pas là. Donc, je maintiens ma demande initiale.
InformationsquelleAutor
31

Le point de sel est d'empêcher les attaquants d'amortir le coût d'une attaque en force brute sur l'ensemble des sites (ou, mieux encore, lors de l'utilisation d'un autre sel pour chaque utilisateur: tous les utilisateurs d'un site) à travers précalculées rainbow tables.

Avec la plaine de hachage, un attaquant peut calculer une telle table une fois (une très longue, coûteuse) et ensuite l'utiliser pour trouver rapidement les mots de passe pour n'importe quel site. Quand un site utilise un fixe, le sel, l'attaquant a pour calculer une nouvelle table spécialement pour ce site. Quand un site utilise une autre de sel pour chaque utilisateur, l'attaquant peut cesser de s'embêter avec "rainbow tables" - il va falloir que par la force brute de chaque mot séparément.

Stocker les sels séparément n'est pas nécessaire pour profiter de cet avantage. En théorie, il serait encore plus sûr, car elle permettrait de neutraliser la faiblesse de dictionnaire ou à court de mots de passe. Dans la pratique, il n'en vaut pas la peine avec car à la fin de la journée, vous avez besoin d'accéder à l'sels quelque part pour vérifier les mots de passe. Aussi, en essayant de les séparer conduirait à des systèmes plus complexes et les plus complexes, un système est, les plus de possibilités pour des trous de sécurité y sont.

Edit: Mes recommandations concrètes:
- De générer à long pseudo-aléatoire de sel pour chaque utilisateur et de les stocker dans la DB
- Utiliser un bcrypt-en fonction de hachage
- idéalement, ne pas mettre en œuvre vous-même, utilisez une bibliothèque existante au lieu
- Merci Mike. Donc, c'est comme de 6 à 1, une demi-douzaine de l'autre... comme Si c'était vous, comment feriez-vous? Quelle est la meilleure pratique dans votre propre esprit?
- Merci Michael. Je suis sûr que votre probablement fatigué de ce fil par maintenant, mais pourriez-vous répondre à quelques questions? Je suis sur 5.3 actuellement et la crypte est une partie de la distribution. Quand vous dites d'utiliser une lib, est à l'aide de PHPs la fonction crypt ok ou pas?
- +1 grande finale de conseils. @Timmay Cela mérite la grosse coche verte 🙂
- C'est OK, mais la phpass bibliothèque de je lien serait encore mieux. Il serait sans doute vous faire économiser un peu de travail et un système de détection automatique de base qui sera utilisé lorsque le système doit fonctionner sur une ancienne version de PHP.
- Exactement comme Michael Borgwardt dit et cela ne peut pas être sous-estimée, vu le niveau de désinformation dans de nombreuses réponses. Michael est à droite sur place: "le stockage de sels séparément n'est pas nécessaire pour profiter de cet avantage". Le point de l'ensemble des sels est de prévenir les tables arc-en-attaque. Un sel, même en clair, tout sert cette fin.
InformationsquelleAutor Michael Borgwardt
15

Oublier à l'aide de sels (en partie pour la raison que vous mentionnez), l'utilisation bcrypt à la place:

Pour une bonne explication, voir: http://codahale.com/how-to-safely-store-a-password/
- Et la grande chose au sujet de bcrypt? Il contredit les affirmations stupides comme le stockage du sel séparément à partir de la table de hachage.... 😛 (+1 pour la mention de bcrypt; j'ai 100% d'accord.)
- lol.. j'ai comme l'auteur du sens de l'humour. C'est une excellente lecture. Merci. 🙂
- Eh bien, si bcrypt est une meilleure façon d'aller, puis c'est ce que je vais utiliser.
- Oui, bcrypt est la meilleure façon d'aller. N'utilisez pas de MD5 ou SHA1; ce genre de conseils est dépassée par au moins 20 ans (façon de parler). Voir: chargen.matasano.com/chargen/2007/9/7/...
- bcrypt est la meilleure façon d'aller jusqu'à preuve cassé. Tout algorithme de hachage, par la pure définition d'un algorithme de hachage, signifie une entrée = une sortie. La vitesse ne donne pas toute la sécurité (qui sait à quelle vitesse nous allons être capables de calculer en un an). Et si un ordinateur n'est pas suffisant pour forcer votre bcrypt de hachage, eh bien, je vais lancer mon logiciel sur un flipper botnet pour obtenir le résultat. Mon point étant que bcrypt n'est pas plus sécurisé que n'importe quel sel+hash autour.
- Ok, donc PHP de la crypte de l'extension de l'utilisation Blowfish, mais vous avez encore besoin de passer un 16 char de sel - vous êtes de retour où vous avez commencé, non?
- Si cela signifie que votre attaquant est d'employer 1000x plus botnet nœuds de craquer le mot de passe, que tout rehaussé la barre beaucoup. (Et le 1000x réfère seulement à PHK de l'algorithme, qui est de 1000 itérations de MD5; bcrypt est encore plus lente que ça).
- De ce que j'ai reçu de rapidement la lecture par le biais de ce lien a été que blowfish est ultra lent ce qui rend plus difficile et beaucoup plus pour avoir accès au mot de passe.
- Oui, exactement, et c'est là que la victoire est.
- Merci À Chris. Je suis tout au sujet de la logique et de faire quelque chose d'aussi lent semble être le billet. Dois-je installer quelque chose de spécial ou de recompiler PHP pour utiliser bcrypt?
- Selon le lien que Riche posté, c'est une mise en œuvre raisonnable de bcrypt en PHP (si ci-dessous 5.3.0): openwall.com/phpass (Ils disent que 5.3.0+ déjà intégré.)
- Ah, c'est cool. Je suis déjà sur la 5.3 donc je suppose qu'il est déjà là, alors. 🙂 Au moins quelque chose est pencher en ma faveur aujourd'hui.
- -1 bcrypt est un excellent outil pour ce travail, mais vous devriez toujours être à l'aide de sels (pour les raisons évoquées par Andrew) - le sel résout un problème différent de la valeur de hachage. L'auteur de cet article est faux.
- Où est NBcrypt?
- vous êtes complètement faux! bcrypt est unique par mot de passe de sel inclus dans la version finale de hachage. Il prend soin de tout, donc tout est correct avec elle.
InformationsquelleAutor Rich
7

Autres réponses sont bonnes, donc je vais juste jeter dans un point de détail que personne n'a mentionné. Vous ne voulez pas utiliser le même sel pour chaque mot de passe parce qu'alors, si deux personnes ont le même mot de passe, ils ont le même hash. Est d'exposer des informations qu'un attaquant peut exploiter.

Vous pouvez utiliser le même sel pour chaque utilisateur, ainsi que Juraj est une bonne idée de combiner le mot de passe avec d'autres non-évolution des champs de base de données (propre à un utilisateur). Mais attention, car cette information est liée au mot de passe. Si vous étiez à hacher le nom d'utilisateur + mot de passe afin de garantir un hachage unique, vous ne seriez pas en mesure de changer le nom d'utilisateur sans créer un nouvel utilisateur et d'exiger d'eux pour définir un nouveau mot de passe.

Comme un exemple d'avoir un unique sel par l'utilisateur et de le ranger aux côtés du hachage de mot de passe, je vais souligner /etc/shadow sur votre système Linux.
```
root@linux:/root# cat /etc/shadow | grep root
root:$1$oL5TTZxL$RhfGUZSbFwQN6jnX5D.Ck/:12139:0:99999:7:::
```
Ici, le oL5TTZxL est le sel et RhfGUZSbFwQN6jnX5D.Ck/ est le hachage. La plaine de texte mot de passe est racine dans ce cas, et l'algorithme de hachage mon système est le MD5 BSD algorithme de mot de passe. (systèmes plus récents que le mien ont de meilleurs algorithmes de hachage)
- Indiv, merci.. Que parfaitement logique. Donc j'ai vraiment besoin de penser à ce que je veux de hachage. Ce qui sur le hachage de l'utilisateur mot de passe avec une clé statique que je suis seule à connaître? Une clé qui se trouve dans mon application?
- Une clé statique serait de fournir un niveau supplémentaire de dissimulation, mais c'est correct lors de l'évaluation de la sécurité de supposer qu'un attaquant a toutes les connaissances de votre système, y compris le code source. Dans ce cas, votre clé statique est juste une statique de sel, et de ne pas augmenter de manière significative la sécurité de votre système.
- Et je pense qu'il devrait être souligné que Linux sécurité de la piste de l'enregistrement peut être considérée comme très bonne et ils sont évidemment stocker le sel en clair dans la "DB". Le point entier de sel est de prévenir les tables arc-en-attaque. Remarque les attaques par force brute. Ayant un sel en clair, c'est pas un problème parce qu'elle est entièrement pleine remplit son objectif: vaincre les tables arc-en-attaque. Le stockage d'un sel en clair n'est pas seulement commune, mais c'est normal: il n'est pas votre sécurité est plus vulnérable à une attaque par force brute. En disant que le sel ne doit pas être stocké en clair, c'est idiot.
InformationsquelleAutor indiv
5

Vous n'avez pas le mot de passe à des fins de comparaison. Vous chiffrer le mot de passe lors de leur tentative de connexion et de comparer la valeur stockée avec la nouvelle valeur chiffrée.
- Ouais, parce que le hachage d'une valeur est d'obtenir le même niveau de hachage de tous les temps, il vous suffit de comparer les deux tables de hachage.
- Ok, ce que je reçois. Je faisais ça avant, mais maintenant que je veux utiliser un sel, je ne comprends pas. Je crois que je vais avoir du mal à comprendre c'est comment le salage un mot de passe est plus sécuritaire que de ne pas saler. Le sel est à la base de données le long du côté de la table de hachage. Si un pirate a la base, comment est-ce si sûr?
- Une meilleure approche serait d'inhiber les attaques par dictionnaire tout à fait. Vous pouvez avoir un maximum de tentative de connexion de dénombrement ou d'augmenter le temps entre les tentatives de connexion (par exemple, par une puissance de n) par la mise en œuvre d'un retard. De ce fait, il est très difficile d'essayer un peu plus que quelques mots de passe dans un laps de temps raisonnable.
- Si vous parlez maximum de connexion d'essais, vous êtes en train de regarder le mauvais modèle de menace. Le droit de la menace modèle est qu'un pirate a juste téléchargé la totalité de votre utilisateur/mot de passe de la table, et veut casser que de nombreux mots de passe qu'ils le peuvent.
- toute l'approche préventive dans l'isolement sont essentiellement inutiles. Je n'étais pas il suggère comme un tout englobant infaillible approche.
- Peut-être. Mais tout cela parler d'maximum d'essais est complètement orthogonale pour le but de l'utilisation salé hachage de mot de passe (ce qui est le cas des OP question); le premier vise à en ligne deviner les mots de passe des attaques, tandis que le second est destiné au mode hors connexion de la fissuration des attaques.
InformationsquelleAutor brian
2

Comme vous l'avez mentionné, les algorithmes de hachage travailler qu'un seul sens (ou seulement si elles sont assez fortes :-D)

Pour votre question au sujet de salage, je vous recommande de le hachage d'un mot de passe avec un statique sel chaîne et certains dynamique de données à partir de la base de données, qui devrait pas changer après une fois créé

C'est un très sûr moyen de stocker des mots de passe, car même si la base de données est compromise, les hackers/crackers encore besoin pour obtenir votre statique de la chaîne de hachage et besoin de deviner comment vous avez appliqué tous les saler..

Par exemple, disons que vous avez un users tableau avec les colonnes:
```
id
username
password
created_at
```
colonnes id et created_at après une fois rempli ne doit jamais être changé..

de sorte que lorsque vous le hachage du mot de passe utilisateur, vous pouvez le faire aussi simple que:
```
<?php
    $staticSalt = '!241@kadl;ap][';
    $userPass = 'my new pass';
    //assuming $user variable is already populated with DB data
    //we will generate new hash from columns and static salt:
    $genPass = sha1($user['id'] . $userPass . $user['created_at'] . $staticSalt);
?>
```
J'espère que cela aide 🙂 cheers

InformationsquelleAutor Juraj Blahunka
2

Hachage des mots de passe est destinée à conserver les mots de passe secret de votre propre administrateur(s).

1) de la tenue de texte en clair les mots de passe de votre base de données serait bien, à l'exception de vos mots de passe peut être utilisé par l'administrateur pour accéder à un autre système.

2) Vous pouvez utiliser un seul global de sel, qui est combiné avec des mots de passe (en ajoutant ou XORing) et ensuite de hachage pour le stockage dans la base de données. Mais qui est vulnérable à un administrateur malveillant ET un arc-en-ciel de table conçu pour que l'une de sel.

3) Vous pouvez avoir une sel pour chaque utilisateur: La base de données sera utilisée pour stocker le sel, et le hachage dérivé du mot de passe/le sel de la combinaison. Cela permettra d'éviter un arc-en-ciel de l'attaque, mais les attaques par force brute sera toujours possible.

4) Enfin, vous pouvez garder votre fonction de hachage d'un secret en utilisant une vitesse limitée de matériel de hachage solution.

Qui est aussi bon que vous pouvez faire. En raison de la nature humaine, les mots de passe ont un domaine limité et sont vulnérables à des attaques de force brute. Nous essayons d'empêcher les administrateurs de obtenir une prise de l'utilisateur mots de passe et ensuite de les utiliser sur d'autres systèmes, ils ne devraient pas avoir accès.

Quelques autres remarques:

a) Vous pouvez utiliser bcrypt sur le mot de passe/le sel de la combinaison de ralentir l'attaquant de l'attaque par force brute. Mais puisque nous sommes en supposant que les administrateurs, ils peuvent être patient.

b) Garder le sel séparé du hachage de mot de passe n'est pas une défense efficace, nous sommes en supposant que les administrateurs, après tout.

c) à l'Aide de données existantes comme un sel est un peu mieux, mais je doute que les données existantes comme beaucoup d'entropie aléatoires de sel.
- Merci Kyle.. je suis toujours là à essayer de comprendre comment utiliser bcrypt. Avez-vous utilisé avant dans le cadre de PHPs distro?
- "L'administrateur" pourrait aussi être quelqu'un qui a trouvé une injection SQL trou dans votre site et a enlevé votre DB schéma et le contenu de votre table utilisateur.
- Bon point sur les administrateurs. Je suis fier de dire que même moi, en tant que concepteur de notre système de mot de passe, ne pouvait pas comprendre toute l'utilisateur mot de passe sans une attaque par force brute. Si je ne peux pas le faire, comment quelqu'un avec moins de connaissances sur le système va?
InformationsquelleAutor Kyle Lahnakoski
1

Salage d'un utilisateur mot de passe est peut-être plus sûr que juste le hachage du mot de passe, car il peut protéger contre de précalcul des attaques.

Par exemple, si un pirate obtient l'accès à votre base de données, et les mots de passe ne sont pas salés, alors il peut aussi regarder la hachages dans sa base de données de hachages (voir http://en.wikipedia.org/wiki/Rainbow_table) pour obtenir les mots de passe d'origine.

InformationsquelleAutor Sam Hartsfield

Vous devez vous connecter pour publier un commentaire.