Meilleures pratiques: salting & peppering mots de passe?

j'ai rencontré une discussion dans laquelle j'ai appris que ce que j'avais fait n'était pas en fait saler les mots de passe mais les éplucher, et j'ai depuis commencé à faire les deux avec une fonction comme:

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

en ignorant l'algorithme de hachage choisi (je veux qu'il s'agisse d'une discussion sur les sels et les poivrons et pas d'algorithmes spécifiques, mais j'utilise un algorithme sécurisé), est-ce une option sécurisée ou devrais-je faire quelque chose de différent? Pour ceux qui ne connaissent pas les Termes:

  • a salt est une valeur générée au hasard habituellement stockée avec la chaîne dans la base de données conçue pour rendre impossible l'utilisation de tables de hachage pour craquer les mots de passe. Comme chaque mot de passe a son propre sel, ils doivent tous être brutalement forcés individuellement afin de les casser; cependant, comme le sel est stocké dans la base de données avec le hachage de mot de passe, un compromis de base de données signifie perdre les deux.

  • A pepper est une valeur statique à l'échelle du site stockée séparément de la base de données (habituellement codée en dur dans le code source de l'application) qui est censée être secrète. Il est utilisé de sorte qu'un compromis de la base de données ne causerait pas la table de mot de passe de l'application entière à être brute-forceable.

est-ce qu'il y a quelque chose qui me manque et est salting & peppering mes mots de passe la meilleure option pour protéger la sécurité de mon utilisateur? Est-il un défaut de sécurité à le faire de cette façon?

Note: supposons, aux fins de la discussion, que l'application et la base de données sont stockées sur des machines distinctes, qu'elles ne partagent pas de mots de passe, etc. donc une violation du serveur de base de données ne signifie pas automatiquement une violation de l'application serveur.

122
demandé sur Charles 2013-06-03 11:15:47

4 réponses

Ok. Vu que j'ai besoin d'écrire sur ce sur et sur , je vais faire une dernière réponse canonique sur pepper seul.

L'Apparente À L'Envers De Poivrons

il semble tout à fait évident que les poivrons devraient rendre les fonctions de hachage plus sûres. Je veux dire, si l'attaquant obtient seulement votre base de données, alors vos mots de passe utilisateurs devrait être sécurisé, Non? Semble logique, non?

C'est pourquoi beaucoup de gens croient que les poivrons sont une bonne idée. Il "a du sens".

La Réalité Des Poivrons

dans les domaines de la sécurité et de la cryptographie," avoir du sens " n'est pas suffisant. Quelque chose doit être prouvable et faire sens pour être considéré comme sûr. En outre, il a à être mises en œuvre dans un maintenable. Le système le plus sûr qui ne peut pas être maintenu est considéré comme non sûr (parce que si une partie de ce la sécurité tombe en panne, tout le système tombe en morceaux).

et les poivrons ne correspondent ni aux modèles prouvables ni aux modèles maintenables...

Problèmes Théoriques Avec Les Poivrons

maintenant que nous avons préparé le terrain, regardons ce qui ne va pas avec les poivrons.

  • donner du hash à quelqu'un d'autre peut être dangereux.

    dans votre exemple, vous faites hash_function($salt . hash_function($pepper . $password)) .

    nous savons par expérience que" juste alimenter " un résultat de hachage dans une autre fonction de hachage peut diminuer la sécurité globale. La raison en est que les deux fonctions de hachage peuvent devenir une cible d'attaque.

    C'est pourquoi des algorithmes comme PBKDF2 utilisent des opérations spéciales pour les combiner (hmac dans ce cas).

    le fait est que bien que ce ne soit pas une grosse affaire, ce n'est pas non plus une chose insignifiante de juste jeter autour. Les systèmes de cryptographie sont conçus pour éviter les cas "qui devraient fonctionner", et se concentrent plutôt sur les cas "conçus pour fonctionner".

    bien que cela puisse sembler purement théorique, ce n'est en fait pas le cas. Par exemple, Bcrypt ne peut pas accepter les mots de passe arbitraires . Ainsi, passer bcrypt(hash(pw), salt) peut en effet conduire à un hachage beaucoup plus faible que bcrypt(pw, salt) si hash() renvoie une chaîne binaire.

  • La conception

    la façon dont bcrypt (et d'autres algorithmes de hachage de mots de passe) ont été conçus est de fonctionner avec un sel. Le concept de poivre n'a jamais été lancée. Cela peut sembler une banalité, mais il ne l'est pas. La raison en est que le sel n'est pas un secret. C'est juste une valeur qui peut être connu à un attaquant. Un poivre par contre, par définition, est un secret cryptographique.

    les algorithmes actuels de hachage de mot de passe (bcrypt, pbkdf2, etc) tous sont conçus pour seulement prendre une valeur secrète (le mot de passe). L'ajout d'un autre secret dans l'algorithme n'a pas été étudié.

    cela ne signifie pas qu'il n'est pas sûr. Cela signifie que nous ne savons pas si c'est sûr. Et la recommandation générale avec la sécurité et la cryptographie est que si nous ne savons pas, ce n'est pas le cas.

    donc tant que les algorithmes ne sont pas conçus et validés par les cryptographes pour une utilisation avec des valeurs secrètes (peppers), les algorithmes actuels ne devraient pas être utilisés avec eux.

  • La Complexité Est L'Ennemi De La Sécurité

    Croyez-le ou pas, la Complexité Est L'Ennemi De la Sécurité . Faire un algorithme qui semble complexe peut être sécurisé, ou il peut ne pas l'être. Mais il y a de fortes chances que ce ne soit pas sûr.

Des Problèmes Importants Avec Des Poivrons

  • il N'est pas maintenable

    votre mise en œuvre de poivrons empêche la possibilité de tourner la clé de poivre. Puisque le poivre est utilisé à l'entrée de la fonction à Sens Unique, vous ne pouvez jamais changer le poivre pour la durée de vie de la valeur. Cela signifie que vous avez besoin de venir avec quelques pirouettes pour obtenir le support de la rotation des clés.

    c'est extrêmement important car il est lorsque vous stockez des secrets cryptographiques. Le fait de ne pas avoir de mécanisme pour faire tourner les clés (périodiquement et après une brèche) est une énorme vulnérabilité de sécurité.

    et votre approche actuelle de pepper exigerait que chaque utilisateur soit d'avoir son mot de passe complètement invalidé par une rotation, ou d'attendre jusqu'à leur prochaine connexion à tourner (qui peut ne jamais être)...

    ce qui fait de votre approche un non-go immédiat.

  • Il Exige Que Vous Rouliez Votre Propre Crypto

    comme aucun algorithme actuel ne supporte le concept d'un poivre, il vous faut soit composer des algorithmes, soit en inventer de nouveaux pour supporter un poivre. Et si vous ne pouvez pas voir immédiatement pourquoi c'est une très mauvaise chose:

    N'importe qui, de l'amateur le plus ignorant au meilleur cryptographe, peut créer un algorithme qu'il lui-même ne peut pas briser.

    JAMAIS rouler votre propre crypto...

La Meilleure Façon

Donc, sur tous les problèmes décrits ci-dessus, il y a deux façons de gérer la situation.

  • Utilisez Les Algorithmes Tels Qu'Ils Existent.

    si vous utilisez bcrypt ou scrypt correctement (avec un coût élevé), tous les mots de passe sauf les plus faibles du dictionnaire devraient être statistiquement sûrs. Le record actuel pour le hachage de bcrypt au coût 5 est de 71k hachures par seconde. À ce rythme, même un mot de passe aléatoire de 6 caractères prendrait des années à craquer. Et compte tenu de mon coût minimum recommandé est de 10, qui réduit les coups de fouet par seconde d'un facteur de 32. On ne parlerait que de 2200 coups de fouet par seconde. À ce rythme, même certaines phrases ou modifications du dictionnaire peuvent être sécuritaires.

    de plus, nous devrions vérifier les faibles classes de mots de passe à la porte et ne pas les laisser entrer. Comme la fissuration de mot de passe devient plus avancé, ainsi devrait les exigences de qualité de mot de passe. C'est toujours un jeu statistique, mais avec une bonne technique de stockage, et des mots de passe forts, tout le monde devrait être pratiquement très sûr...

  • Chiffrer Le Hachage De Sortie Avant Le Stockage

    il existe dans le domaine de la sécurité un algorithme conçu pour gérer tout ce que nous avons dit ci-dessus. C'est un algorithme de chiffrement par bloc. C'est bien, parce que c'est réversible, donc on peut tourner les touches (yay! la maintenabilité!). C'est bien parce qu'ils sont utilisés comme prévu. C'est bien parce que ça ne donne aucune information à l'utilisateur.

    regardons encore cette ligne. Disons qu'un attaquant connaît votre algorithme (qui est nécessaire pour la sécurité, sinon, c'est la sécurité par l'obscurité). Avec une approche traditionnelle au poivre, l'attaquant peut créer un mot de passe sentinelle, et comme il connaît le sel et la production, il peut forcer le poivre. Ok, c'est un long shot, mais c'est possible. Avec un cryptogramme, l'attaquant n'obtient rien. Et comme le sel est aléatoire, un mot de passe sentinelle ne l'aidera pas. Donc le mieux qu'il leur reste est d'attaquer la forme cryptée. Ce qui signifie qu'ils ont d'abord attaquer votre hachage chiffré à récupérez la clé de cryptage, puis attaquez les hachures. Mais il y a un lot de recherche sur l'attaque des chiffreurs, donc nous voulons compter sur cela.

TL/DR

N'utilisez pas de poivrons. Il y a une foule de problèmes avec eux, et il y a deux meilleures façons: ne pas utiliser de secret côté serveur (Oui, c'est ok) et chiffrer le hachage de sortie en utilisant un chiffrement de bloc avant le stockage.

275
répondu ircmaxell 2017-05-23 12:10:06

poing nous devrions parler du avantage exact d'un poivre :

  • Le poivre peut protéger la faiblesse des mots de passe à partir d'une attaque de dictionnaire, dans le cas particulier, où l'attaquant a accès en lecture à la base de données (contenant les valeurs de hachage), mais n'a pas accès au code source avec le poivre.

un scénario typique serait une injection SQL, des sauvegardes jetées, des serveurs abandonnés... Ils les situations ne sont pas aussi rares que cela en a l'air, et souvent pas sous votre contrôle (serveur-hébergement). Si vous utilisez...

  • un sel unique par mot de passe
  • un algorithme de hachage lent comme BCrypt

...les mots de passe forts sont bien protégés. Il est presque impossible de forcer un mot de passe fort dans ces conditions, même si le sel est connu. Le problème sont les mots de passe faibles, qui font partie d'une force brute dictionnaire ou dérivent d'entre eux. Une attaque de dictionnaire les révèlera très vite, parce que vous testez seulement les mots de passe les plus communs.

La deuxième question est comment appliquer le poivre ?

une façon souvent recommandée d'appliquer un poivre, est de combiner le mot de passe et le poivre avant de le passer à la fonction de hachage:

$pepperedPassword = hash_hmac('sha512', $password, $pepper);
$passwordHash = bcrypt($pepperedPassword);

il y a une autre façon encore meilleure:

$passwordHash = bcrypt($password);
$encryptedHash = encrypt($passwordHash, $serverSideKey);

cela permet non seulement d'ajouter un secret côté serveur, mais aussi d'échanger $serverSideKey, si cela est nécessaire. Cette méthode implique un peu plus de travail, mais si le code existe (bibliothèque) il n'y a aucune raison de ne pas l'utiliser.

18
répondu martinstoeckli 2013-06-03 09:48:34

le point de sel et de poivre est d'augmenter le coût d'une recherche de mot de passe pré-calculé, appelé une table arc-en-ciel.

en général, il est difficile d'essayer de trouver une collision pour un simple hachage (en présumant que le hachage est sûr). Cependant, avec des hachures courtes, il est possible d'utiliser l'ordinateur pour générer tous les hachures possibles dans une recherche sur un disque dur. C'est ce qu'on appelle une table arc-en-ciel. Si vous créez une table arc-en-ciel vous pouvez alors sortir dans le monde et trouver rapidement plausable mots de passe pour n'importe quel hachage (unsalted unpeppered).

le but d'un poivre est de rendre la table arc-en-ciel nécessaire pour hacker votre liste de mots de passe unique. Perdre ainsi plus de temps sur l'attaquant de construire la table arc-en-ciel.

le but du sel est cependant de rendre la table arc-en-ciel pour chaque utilisateur être unique à l'utilisateur, en augmentant encore la complexité de l'attaque.

vraiment le point de la sécurité informatique est presque jamais de faire (mathématiquement) impossible, juste mathématiquement et physiquement impossible (par exemple dans des systèmes sécurisés il faudrait tout l'entropie dans l'univers (et plus) pour calculer un unique mot de passe utilisateur).

2
répondu Aron 2013-06-03 07:32:12

ne peut pas voir stocker une valeur codée en dur dans votre code source comme ayant une pertinence de sécurité. C'est la sécurité par l'obscurité.

si un hacker acquiert votre base de données, il sera en mesure de commencer brute forçant vos mots de passe utilisateur. Ce hacker ne tardera pas à identifier votre pepper s'il réussit à déchiffrer quelques mots de passe.

1
répondu Sven 2013-06-03 07:23:06