2014-04-24 1 views
0

Je travaille sur un site qui est (essaie d'être) super sécurisé. Je lis beaucoup sur le hachage des mots de passe et l'utilisation de sels, mais tout n'est pas clair pour moi. Je voudrais utiliser l'algorithme de hachage sha-256 avec du sel. Je sais à propos des sels que tous devraient être unique par mot de passe par utilisateur.Mot de passe hachage et sels en PHP

Je me demande si j'utilise le mot de passe comme sel aussi? Hash le mot de passe avec sha256, puis hachez-le avec un autre algorithme et l'utiliser comme sel. De cette façon, je ne dois pas stocker le sel dans la base de données. Est-ce possible? ou devrais-je générer une chaîne aléatoire?

+1

Non, utilisez 'password_hash' - c'est la manière standard de hacher et de saler les mots de passe avec PHP. L'idée avec ceci est que les algorithmes de hachage sont délibérément lents, et ne peuvent pas être parallélisés, alors que SHA-256 pourrait être trop rapide. Si votre algorithme de hachage est rapide, les mots de passe hachés peuvent être dérivés simplement par une recherche par force brute. – halfer

+0

duplication possible de [Secure hash et le sel pour les mots de passe PHP] (http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords) – halfer

+0

Ce n'est pas la même question mais a une bonne description, merci. Peut-être que je n'étais pas si clair. Je veux utiliser mon mot de passe comme du sel aussi sous une forme hachée. – Bakayaro

Répondre

0

Non, c'est toujours un algorithme unidirectionnel.

Si un autre utilisateur utilise le même mot de passe, la valeur de hachage sera la même que celle du hachage du premier utilisateur. Cela manque le point que les valeurs de hachage doivent être différentes pour chaque utilisateur et chaque entrée de passe.

Je suggère d'utiliser la date d'enregistrement d'un utilisateur (par exemple) comme sel. De cette façon, pour chaque utilisateur et chaque passage, l'algorithme de hachage sera différent (d'accord, si deux utilisateurs ont la même passe ET la même date d'enregistrement, elle sera la même).

Ou peut-être vous pouvez utiliser l'ID utilisateur pour le sel, ou une combinaison entre l'ID utilisateur et reg.date et le nom d'utilisateur.

Edit: Votre approche est mieux que actualy hachant avec algorithme connu sans sel, mais pire que hachage + sel propper.

Ce que vous faites est simplement d'appliquer une fonction de hachage personnalisée. Cela ne peut pas être facilement forcé par la force sans connaître l'algorithme personnalisé, mais il est vulnérable aux autres attaques.

Et je suggère de ne pas placer une table avec le nom "SALT" dans la DB, car si DB est piraté l'attaquant wii obtenir les mots de passe ET les sels pour eux.

+0

mais les noms d'utilisateur sont publics, n'est-ce pas un problème? ou devrais-je le hacher aussi? – Bakayaro

+0

Traditionnellement, les sels ont été stockés dans la table utilisateur non cryptée, autant que je sache. Ils sont là juste pour augmenter la complexité de tenter d'inverser le hachage. [Cet article de WP] (https://en.wikipedia.org/wiki/Salt_%28cryptography%29#Benefits) fait référence à un «sel public», ce qui signifie, à mon avis, que le sel peut être lu de la table . – halfer

+0

Probbaby pas, dépend de ce que vous avez l'intention de faire. Si les noms sont hachés, vous ne pourrez pas dire à un utilisateur quel est son nom d'utilisateur. Dans la plupart des cas, les noms d'utilisateur ne sont pas des informations privées et les applications les affichent sur la page, permettent aux autres utilisateurs de les voir et ainsi de suite. Il existe cependant une approche pour diviser le nom de connexion et le nom d'utilisateur - les journaux des utilisateurs avec son nom de connexion (on peut utiliser le courrier pour cela) et se présenter à d'autres personnes avec un nom différent.Dans ce cas, les noms de connexion peuvent être privés et peuvent être hachés. – user1328370

Questions connexes