Convaincre mon manager d'utiliser des sels
Mon responsable dit que nous n'avons pas besoin de saler nos mots de passe car les gens ne sont pas susceptibles d'utiliser le même mot de passe car ils ont tous des langues maternelles différentes, en plus des sites Web sur lesquels ils sont actifs. Quel est le meilleur contre-argument à cela?
Je ne sais pas d'où tu viens. Tout d'abord, son opinion est contraire aux meilleures pratiques de l'industrie considérée telles que définies par NIST . De plus, votre manager a dangereusement tort. Plus il y a d'utilisateurs, plus il est probable qu'ils obtiennent les mêmes mots de passe pour plusieurs utilisateurs. Les entreprises suivantes le font également et je suis tout à fait convaincu qu'elles ont une base d'utilisateurs mondiale plus importante que votre site Web:
- Gmail
Une autre raison que vous pouvez expliquer dans une perspective commerciale est le risque de dommages à l'image/à la marque lorsque vous obtenir une publicité négative . Pour vous donner un exemple, Adobe a utilisé une mauvaise implémentation pour le stockage des mots de passe, ce qui conduit au même problème que vous rencontrez actuellement: la valeur résultant du hachage (dans le cas d'Adobe, ils utilisaient le chiffrement plutôt que le hachage), le mot de passe était le même pour plusieurs les utilisateurs s'ils utilisaient le même mot de passe (dans leur cas, parce qu'ils n'utilisaient pas un IV pendant le cryptage symétrique, mais ce n'est pas pertinent). Cela a provoqué une énorme tempête de publicité négative, après tout, une entreprise Internet devrait adhérer à quelque chose d'aussi simple que le hachage de mot de passe, non? Le coût financier résultant d'une telle publicité négative peut être important.
Selon le pays où vous vivez et les lois utilisées, la direction peut également être tenue personnellement responsable s'il est déterminé qu'elle a fait preuve de négligence lorsqu'elle a vient à protéger la confidentialité des données (si des mots de passe fissurés sont utilisés pour obtenir des données personnelles des utilisateurs par exemple). En fonction du type d'informations stockées, financières, médicales, cartes de crédit, différentes règles peuvent également s'appliquer, ce qui peut entraîner d'autres types d'amendes.
C'est quelque chose qui pourrait ne pas être directement pertinent pour le hachage de mot de passe, mais qui pourrait s'avérer utile si votre responsable prend de mauvaises décisions. Assurez-vous donc de faire des copies des e-mails où vous expliquez clairement le problème et enregistrez également la réponse de vos gestionnaires. (juste pour couvrir ton propre cul)
Le fait que vous n'utilisez pas de sels signifie également que vous n'utilisez pas un algorithme de hachage correct, car ceux-ci prennent souvent soin de générer des sels et d'effectuer une quantité d'itérations. Les trois algorithmes acceptés sont:
- PBKDF2
- bcrypt
- déchiffrer
Le but principal des sels est d'empêcher un attaquant d'économiser du travail en comparant un hachage calculé unique avec tous les hachages stockés. Ce problème est indépendant du fait que les mots de passe sont uniques ou non.
Sans sels, l'attaquant peut simplement parcourir sa liste de mots de passe possibles, calculer le hachage pour chacun, puis vérifier si le résultat correspond à l'un des hachages stockés. Un seul calcul par estimation est donc requis.
Avec des sels, l'attaquant doit parcourir sa liste pour chaque utilisateur, car il ne peut pas réutiliser les résultats. Cela l'oblige à faire un calcul par supposition et par utilisateur. Cela augmente considérablement les coûts de l'attaque.
Mais comme Lucas l'a déjà dit, le vrai problème ici est que vous n'utilisez pas un algorithme approprié. Les sels ne sont qu'un aspect du hachage de mot de passe.
Le "meilleur" contre-argument dépend de ce que vous essayez de réaliser.
Si vous voulez simplement avoir raison sur le plan scientifique, il suffit de dire que les sels ne sont pas, et n'ont jamais été, une méthode pour faire face à deux utilisateurs distincts choisissant le même mot de passe. En particulier parce que deux utilisateurs qui choisissent le même mot de passe ne posent pas de problème au départ, il n'y a donc rien à corriger. Les sels permettent d'éviter les attaques parallèles, y compris l'utilisation de tables précalculées. Le manque de sels était le péché capital de LinkedIn .
Maintenant, avoir raison n'a d'effet que sur les personnes qui sont prêtes à reconnaître qu'elles peuvent avoir tort ou du moins être incomplètement informées. Ce que vous citez de votre manager tend à démontrer qu'il est à la fois totalement incompétent sur le sujet, et également convaincu qu'il le maîtrise totalement. Si vous voulez convaincre ce manager qu'il a tort, alors, bonne chance à ce sujet. Ce que les gens craignent le plus, c'est d'admettre, même implicitement, qu'ils ont dit quelque chose de stupide.
Si vous voulez que votre organisation passe réellement au hachage de mot de passe approprié (lisez this ), alors ce que vous pourriez être en mesure de faire est de convaincre d'autres personnes que ce que le manager vient de dire est du pur charabia, que cela n'a même pas assez de sens pour se tromper. Si le gestionnaire devient isolé, il peut fermer les yeux sur la mise en œuvre du hachage de mot de passe approprié, sans, bien sûr, le reconnaître. Là encore, l'argument scientifiquement correct n'est pas nécessairement le plus efficace. En Amérique du Nord (en particulier dans les régions sous influence britannique comme la Nouvelle-Angleterre), les réunions d'affaires visent à éviter les affrontements et à diluer la responsabilité, vous devez donc en répartir peur, incertitude et doute : assurez-vous de souligner que votre les concurrents se tournent vers les hachis salés, et ne pas faire de même risque de perdre une part de marché. En Europe du Sud, les réunions sont des batailles rituelles pour établir la hiérarchie, alors criez, grognez, menacez et utilisez le sarcasme pour gagner le soutien de la foule: vous ne gagnez pas en ayant raison , mais en étant assertif .
L'un des types d'arguments les plus efficaces, de manière générale, est l'appel à l'autorité. Dans Publication spéciale NIST SP800-118 (actuellement en projet), on peut voir:
Un autre exemple de faiblesse d'un algorithme de hachage est que certains algorithmes n'utilisent pas de salage.
"Pas de sel" = "faiblesse". Le NIST le dit. Qui est ce manager qui pense qu'il est plus intelligent que le NIST?
Dans un certain sens, si vous vous disputez sur le sel, vous avez déjà raté le bateau. L'état de l'art en matière de sécurité du stockage des mots de passe va bien au-delà de la question "à saler ou à ne pas saler", et est depuis passé au comptage des itérations.
Mais commençons par les bases. Voici une réponse que j'ai écrite il y a peu de temps qui était étonnamment populaire. Cela explique pourquoi le sel est meilleur, et beaucoup de gens ont dit qu'il faisait cliqueter quelque chose là où d'autres explications étaient tombées à plat. C'est plus ou moins ce que vous demandez - montrez-le à votre patron si vous pensez que cela fera du bien:
Pourquoi les hachages salés sont-ils plus sûrs?
Mais le point important, c'est le dernier qui a été fait. C'est-à-dire que stocker un hachage SHA1 salé et le qualifier de bon n'est plus considéré comme responsable. La puissance de calcul a atteint le point où des milliards de hachages par seconde ne sont plus théoriques, vous permettant de traverser tout l'espace 32 bits d'une attaque par force brute plus rapidement que ce qu'il faudrait pour expliquer ce que vous faites.
Maintenant, l'accent est mis sur le fait de forcer l'attaquant à résoudre le problème des milliers ou des centaines de milliers de fois juste pour faire une supposition. C'est là que PBKDF2 apparaît (portant son costume et sa cravate émis par le NIST), ainsi que scrypt et ses amis (l'air débraillé mais puissant).
Quel algorithme vous choisissez n'est pas vraiment la clé. Ils résolvent tous à peu près le même problème, juste de différentes manières avec des accents différents. Mais vous devez utiliser quelque chose - un algorithme qui rend difficile la force brute, même un seul mot de passe. La raison est simple: c'est la norme de l'industrie, elle est mesurablement et prouvée plus sûre, et son utilisation ne coûte pas cher. Mettez ces facteurs ensemble et il devient rapidement évident que si vous ne faites pas le faites, alors vous pouvez être considéré comme négligent en cas de violation.
Le meilleur argument est de retirer ne liste des mots de passe les plus courants et de montrer qu'environ 1% de vos utilisateurs choisiront "123456". Le deuxième meilleur serait de retirer un analyse de fuite de mot de passe pour un grand site et de montrer que seulement environ la moitié de vos utilisateurs parviendront à trouver un mot de passe unique.
Vous devez souligner deux points:
L'utilisation d'un sel réduit la valeur d'un fichier volé contenant des mots de passe hachés. Cela est vrai quelle que soit la ou les langues parlées par les utilisateurs du système, car un attaquant qui possède une table Rainbow pour votre algorithme de hachage peut l'utiliser pour inverser le mot de passe haché quelle que soit la langue maternelle de la personne qui l'a choisi. mot de passe.
L'utilisation d'un sel est presque gratuite. Cela ne vous rapporte presque rien de l'exclure, et même selon l'estimation actuelle de votre responsable, l'exclure n'est que "susceptible" de ne pas causer de problème de sécurité grave. Par conséquent, utilisez-le.
Il y a une objection que votre manager pourrait soulever contre le premier point, mais j'espère que non: "nous utilisons notre propre algorithme de hachage personnalisé, donc il n'y a aucun danger qu'une table Rainbow existe pour cela". Dans ce cas, vous devez également justifier l'utilisation d'un algorithme de hachage de mot de passe standard.
Je trouve aussi:
[les utilisateurs] ont tous des langues maternelles différentes
être une hypothèse bizarre à faire sur un système. Si vous vous basez sur une hypothèse pour votre analyse de sécurité, votre système devient non sécurisé (ou en tout cas, non évalué pour la sécurité) dès que l'hypothèse est rompue. Donc, après avoir utilisé cette hypothèse pour la sécurité, vous devez ensuite faire en sorte que deux utilisateurs du produit n'aient pas la même langue maternelle . Pourquoi diable voudrait-on restreindre leur système de cette façon, et en particulier comment l'application de cette restriction sera-t-elle plus facile que l'utilisation d'un sel?
Cependant, dans ce cas, cette hypothèse ne conduit même pas à la conclusion que votre gestionnaire fait que le sel n'est pas nécessaire (pour la raison que je donne ci-dessus). Donc, la question de savoir si l'hypothèse peut être maintenue est assez hors de propos étant donné qu'elle n'aide pas!
Enfin, pour info, il y a une raison spécifique pour laquelle mon premier point ci-dessus contredit l'analyse de votre manager:
peu susceptible d'utiliser le même mot de passe
est une analyse erronée de la faiblesse que le sel corrige. Peu importe à l'attaquant que deux utilisateurs du système aient le même mot de passe ou non, à moins que l'attaquant ne soit l'un de ces deux utilisateurs et ne connaisse donc le mot de passe qu'ils partagent. Les sels ne se défendent pas seulement contre cette attaque, ils se défendent également contre les attaques de la table Rainbow. Donc, même si cette attaque inhabituelle par un de vos utilisateurs avec le même mot de passe était impossible sur votre système, vous auriez toujours besoin de sels.
Je suppose que c'est plus un problème humain qu'un problème technique. Par conséquent, vous devez répondre avec des compétences générales plutôt qu'avec des explications techniques. Si votre manager réagit positivement aux explications techniques, choisissez une des réponses avant.
Si vous voulez aller du côté des compétences non techniques, vous pouvez essayer quelques choses:
- Le plus important à retenir: votre patron est votre patron. Ne vous fâchez pas contre lui, sinon vous serez malchanceux.
- Essayez de ne pas lui poser de questions auxquelles il ne peut pas répondre. Posez plutôt des questions indirectes sous forme de phrases simples.
- Essayez de comprendre son point de vue et ses arguments.
- Appliquez la paraphrase.
- Ne riez jamais.
- Ne soyez jamais impoli.
- Lisez le livre de Dale Carnegie "Comment gagner des amis et influencer les gens".
Un exemple de dialogue pourrait ressembler à ceci (sachez que je ne suis pas un locuteur natif anglais):
Boss: "Nous n'avons pas besoin de sels."
Vous: "Nous n'avons pas besoin de cette protection supplémentaire."
Boss: "Oui, nos utilisateurs ne réutilisent pas le même mot de passe."
Vous: "Le mot de passe fort est déjà sécurisé."
Patron: "C'est vrai."
Vous: "D'accord, je comprends. Nos utilisateurs sécurisent le mot de passe et nous vivons simplement sans sels."
Boss: "Ouais, peut-être pas tous les utilisateurs ..."
Vous: sourire
Ou comme ça:
Boss: "Nous n'avons pas besoin de sels."
Vous: "L'avantage d'utiliser des sels ne vaut pas la peine."
Patron: "C'est exact."
Vous: "Donc, nous supprimons le sel de la liste des tâches et continuons avec le reste."
Boss: "D'accord, nous avons déjà pris du retard."
Vous: "Si nous respections le calendrier d'une autre manière, pouvons-nous mettre en œuvre le sel."
Boss: "Non, je ne comprends pas ce concept de sel."
Vous: "Ce truc cryptographique est toujours difficile à comprendre."
Patron: "Même quand j'ai lu un article, je n'ai pas eu la moindre idée."
Vous: "Ce qui vous fait penser que c'est beaucoup d'efforts."
Patron: "Oui, nous perdrons environ deux jours."
Vous: "Avec l'aide d'un cadre, je peux le faire en 2 heures."
Patron: "Vraiment?"
Vous: sourire
Notez qu'il n'y a aucun point d'interrogation. Le patron n'est jamais contraint de répondre à des questions dont il ne connaît peut-être pas la réponse.
Malheureusement, il est assez difficile d'appliquer de telles techniques si vous ne l'avez jamais fait auparavant.
Si cette approche ne fonctionne pas bien non plus, il y a une autre option:
Il suffit de l'implémenter. Cela ne devrait pas être trop d'effort et votre patron ne le remarquera probablement pas, sauf qu'il fait une révision de code ou regarde des tables de base de données.
Il suffit de jeter quelques hachages (peut-être son propre mot de passe) dans Google. Il retournera probablement le mot de passe. Son hachage faible est comme aucun hachage du tout.
https://www.google.de/search?q=a94a8fe5ccb19ba61c4c0873d391e987982fbbd
Si cela ne le convainc pas de chercher un nouvel emploi ...