ANortonsmith
2013-08-29 05:44:50 UTC
Après avoir lu cet article, je peux voir les avantages du hachage de mots de passe comme deuxième couche de défense, dans le cas où un intrus accède à une base de données de mots de passe. Ce que je ne comprends toujours pas, c'est ceci:
Le hachage de mot de passe n'est-il pas important uniquement si le système est suffisamment faible pour permettre à un intrus d'accéder à la base de données de mots de passe? Si tel est le cas, pourquoi une telle importance est-elle mise sur la création de bases de données de mots de passe sécurisées, plutôt que sur des systèmes sécurisés qui empêcheraient l'accès non autorisé aux informations importantes des utilisateurs? Comment se fait-il que les bases de données de mots de passe hachés soient si souvent volées?
Le hachage n'est pas une deuxième couche de défense, c'est une police d'assurance. Mettre en œuvre la technologie en partant du principe que le système sera éventuellement compromis. Si Sony, Blizzard, Dropbox, Apple sont incapables de sécuriser leurs systèmes, qu'est-ce qui vous fait penser que vous le pouvez? Ce n'est rien contre vous, mais si les entreprises avec des ressources presque illimitées dont l'activité principale dépend de la sécurité de leur système, ne peuvent pas protéger leur système, vous n'avez aucune chance. Mettez donc en œuvre une technologie pour éviter les dommages quand cela se produit.
Dans le cas d'@Ramhound IIRC Sony, il ne s'agissait pas de dépenser beaucoup d'efforts mais de déraper; mais une négligence grave causée par personne ne considérant la possibilité de se faire pirater. En tant que tel, je ne suis pas sûr qu'ils soient un bon exemple.
@DanNeely - Le fait qu'ils n'aient pas envisagé cette possibilité est exactement la raison pour laquelle je les ai utilisés (également le fait qu'ils sont faciles à retenir). Je pourrais passer à Twitter, Linken, la société mère de Gizmodo si vous en voulez plus. Le point de la déclaration, supposez que cela se produira et faites ce que vous pouvez, pour empêcher la famille de lapins qui sera tuée après que cela se produise.
Un autre point: les processeurs sont aujourd'hui si rapides et les méthodes d'attaque si sophistiquées qu'il est conseillé de ** ne pas ** utiliser de hachage pour crypter les mots de passe. Pourquoi? Le calcul d'un hachage est une opération très rapide de par sa conception, car le cas d'utilisation d'origine était de vérifier l'intégrité du fichier. Pour chiffrer les mots de passe, il est préférable d'utiliser un algorithme qui prendra beaucoup plus de temps à calculer qu'un hachage, mais qui reste assez rapide lors de la vérification des mots de passe individuels. Cela ralentira les attaques par force brute. [Bcrypt] (http://goo.gl/T2g0yv) est l'un de ces algorithmes. [Pour en savoir plus, cliquez ici.] (Http://goo.gl/aiyPKQ)
@Andy En fait, saler un mot de passe n'affectera pas vraiment le temps nécessaire à la force brute. C'est parce que si quelqu'un a les mots de passe de hachage, il pourrait probablement aussi obtenir le sel.
@ponsfonze Je suis désolé, mais je pense que vous devez lire davantage sur le salage. Un sel n'est pas du tout censé être un secret, il suppose que quelqu'un qui obtient le hachage obtiendra également les sels. http://en.wikipedia.org/wiki/Salt_%28cryptography%29. Le but des sels est de vaincre les tables arc-en-ciel précalculées.
@ponsfonze Si vous craquez un mot de passe, vous avez raison - il n'accélère pas. Cependant, en cas de fissuration massive de toute la base de données, vous devez déchiffrer chaque mot de passe séparément. S'ils ne sont pas salés, vous pouvez simplement hacher "monkey" et obtenir tous les utilisateurs qui l'ont comme mot de passe. Comme ils sont du sel, vous devez hacher le "singe" avec chaque sel unique. (Étant donné qu'il peut y avoir des milliers de mots de passe dans la base de données, cela signifie qu'il y a beaucoup plus de travail à faire pour les traiter).
Il est incorrect de dire que les "anciens" algorithmes de hachage sont rapides et les "nouveaux" lents. La plupart des algorithmes de hachage n'ont jamais été conçus pour être utilisés pour les mots de passe et il y en a beaucoup de nouveaux qui ne conviennent absolument pas. Ce n'est pas le sujet de cette question, mais assurez-vous essentiellement de faire vos devoirs et de choisir un algorithme de hachage solide et digne de confiance, sinon vos utilisateurs seront en danger.
@Andy en fait, les hachages les plus récents ont tendance à être plus rapides. [SHA-3] (http://en.wikipedia.org/wiki/SHA-3) a été spécifiquement choisi * parce que * c'est si rapide * (enfin, et parce qu'il est si différent de SHA-2 ..) *
@BlueRaja-DannyPflughoeft Oui, j'avais découvert que j'avais tort sur cet aspect.
@Andy Merci de m'avoir fourni ce lien. Je ne sais pas où vous allez avec le but d'un sel avec mon commentaire parlant des effets de temps de calcul du hachage des mots de passe avec un sel.
@MaciejPiechotka Merci d'avoir soulevé le point où dans le cas de hachages de force brute dans une base de données entière non salée, le temps de calcul sera réduit en n'ayant pas à recalculer le même hachage pour chaque mot de passe. Cependant, gardons également à l'esprit que des milliers de mots de passe ou plus à déchiffrer peuvent être insignifiants à l'avenir lorsque les processeurs deviennent exponentiellement plus rapides, ou c'est ce que certains ont prévu.
@ponsfonze: Toujours le salage le rend 1000 fois plus lent quelle que soit la technologie utilisée (ou 1000000 pour 1000000 utilisateurs) - bien sûr, cela fait moins de différence entre 1s et 20 min puis 1 jour et 3 ans mais le premier exemple utilisé beaucoup trop de hachage ou de mots de passe de toute façon . Les améliorations des processeurs peuvent être combattues par des problèmes plus difficiles (algorithmes de mémoire dur, etc.)