La réponse courte

La réponse courte est: "Vous ne serez donc pas frappé par un recours collectif de 5 millions de dollars." Cela devrait être une raison suffisante pour la plupart des PDG. Le hachage des mots de passe est beaucoup moins cher.

Mais plus important encore: il ne suffit pas de hacher simplement les mots de passe comme vous l'avez suggéré dans votre question. Vous aurez toujours le procès. Vous devez en faire plus.

Pourquoi vous devez faire plus prend un peu plus de temps à expliquer. Prenons donc le long chemin pendant un moment pour que vous compreniez ce que vous expliquez, puis nous tournerons autour de votre synopsis de 5 minutes.

Le hachage n'est que le début

Mais commençons par ça. Supposons que vous stockiez les mots de passe de vos utilisateurs comme ceci:

  # id: user: password1: alice: pizza2: bob: passw0rd3: carol: baseball  

Maintenant , disons qu'un attaquant parvient à obtenir plus d'accès à votre système que vous ne le souhaiteriez. Il n'est là que pendant 35 secondes avant que vous détectiez le problème et que vous fermiez le trou. Mais au cours de ces 35 secondes, il a réussi à récupérer votre base de données de mots de passe. Oui, vous avez commis une erreur de sécurité, mais vous l'avez corrigée maintenant. Vous avez corrigé le trou, corrigé le code, mis à jour votre pare-feu, quel qu'il soit. Alors tout va bien, maintenant, non?

Eh bien, non, il a votre base de données de mots de passe.

Cela signifie qu'il peut désormais usurper l'identité de chaque utilisateur de votre système. La sécurité de votre système est détruite. La seule façon de récupérer est de recommencer avec une NOUVELLE base de données de mots de passe, obligeant chacun à changer son mot de passe sans utiliser son mot de passe existant comme une forme d'identification valide. Vous devez les contacter hors bande via une autre méthode (téléphone, e-mail ou autre) pour vérifier leur identité afin de recréer leurs mots de passe, et en attendant, toute votre opération est morte dans l'eau.

Et si vous ne le voyiez pas voler la base de données de mots de passe? Rétrospectivement, il est peu probable que vous le voyiez réellement se produire. La façon dont vous le découvrirez probablement est de remarquer une activité inhabituelle sur les comptes de plusieurs utilisateurs. Peut-être que pendant des mois, c'est comme si votre système n'avait aucune sécurité et que vous ne compreniez pas pourquoi. Cela pourrait ruiner votre entreprise.

Nous avons donc haché

Au lieu de stocker le mot de passe, nous stockons un hachage du mot de passe. Votre base de données ressemble maintenant à ceci:

  # id: user: sha11: alice: 1f6ccd2be75f1cc94a22a773eea8f8aeb5c682172: bob: 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb533f1cc98bc1ed7921cb533: carol9d8a2c8a2c2c: car1c8a2c2c2c2c2c2c: que vous stockez est un jeton opaque qui peut être utilisé pour  vérifier  si un mot de passe est correct, mais ne peut pas être utilisé pour  récupérer  le mot de passe correct.  
 Eh bien, presque. Google ces hachages, je vous défie. 
 
 Nous sommes donc passés à la technologie des années 1970. Toutes nos félicitations. Nous pouvons faire mieux. 
 
 Donc nous salons 
 
 J'ai passé un long moment à répondre à la question de savoir pourquoi saler les hachages, y compris des exemples et des démonstrations de la façon dont cela fonctionne dans le monde réel. Je ne reprendrai pas la discussion sur le hachage ici, alors allez-y et lisez l'original: 
 
  Pourquoi les hachages salés sont-ils plus sécurisés? 
 
 Assez amusant , hein? OK, maintenant nous savons que nous devons saler nos hachages ou nous pourrions aussi bien ne jamais avoir haché les mots de passe pour commencer. Nous en sommes maintenant à la technologie des années 1990. Nous pouvons encore faire mieux. 
 
 Nous répétons donc 
 
 Vous avez remarqué ce bit au bas de la réponse que j'ai liée ci-dessus, n'est-ce pas? Le peu sur bcrypt et PBKDF2? Ouais, il s'avère que c'est vraiment important. Avec la vitesse à laquelle le matériel peut effectuer des calculs de hachage aujourd'hui ( merci, bitcoin!), un attaquant doté d'un matériel standard peut détruire tout votre fichier de mots de passe hachés et salés en quelques heures. , calculant des milliards, voire des billions de hachages par seconde. Vous devez les ralentir. 
 Le moyen le plus simple de les ralentir est de simplement leur faire travailler plus. Au lieu de calculer un hachage pour vérifier un mot de passe, vous devez calculer 1000. Ou 100 000. Ou quel que soit le nombre qui vous convient. Vous pouvez également utiliser  scrypt  ("ess-crypt"), qui nécessite non seulement beaucoup de puissance CPU, mais aussi beaucoup de RAM pour faire le calcul, rendant le matériel dédié que j'ai lié ci-dessus largement inutile . 
 
 Il s'agit de l'état actuel de la technique. Félicitations et bienvenue dans la technologie  d'aujourd'hui . 
 
 Avons-nous terminé? 
 
 Que se passe-t-il maintenant lorsque l'attaquant saisit votre fichier de mot de passe? Eh bien, maintenant, il peut le battre hors ligne au lieu de faire des tentatives de supposition en ligne contre votre service. Malheureusement, une bonne partie de vos utilisateurs (4% à 12%) aura utilisé le mot de passe «123456» ou «mot de passe» à moins que vous ne les empêchiez activement de le faire, et l'attaquant tentera de les deviner en premier. 
 
 Si vous voulez assurer la sécurité des utilisateurs, ne les laissez pas utiliser "mot de passe" comme mot de passe. Ou l'un des autres top 500, d'ailleurs.  Il existe un logiciel pour rendre le calcul précis de la force des mots de passe facile (et gratuit). 
 
 Mais aussi, l'authentification multifacteur n'est jamais un mauvais appel. Il est  facile d’ajouter à n’importe quel projet. Donc vous pourriez aussi bien. 
 
 Maintenant, vos 5 minutes de gloire 
 
 Vous êtes devant votre patron, il vous demande pourquoi vous devez  utiliser PBKDF2 ou similaire  pour hacher vos mots de passe. Vous évoquez le recours collectif de LinkedIn et dites: "C'est le niveau minimum de sécurité  légalement  attendu dans l'industrie. Rien de moins est littéralement de la négligence." Cela devrait prendre beaucoup moins de 5 minutes, et si votre patron n'est pas convaincu, c'est qu'il n'écoutait pas. 
 Mais vous pourriez continuer: "Le coût de la mise en œuvre de la technologie de hachage est négligeable, alors que le coût de  ne pas  la mettre en œuvre pourrait être de plusieurs millions ou plus." et "En cas de violation, une base de données correctement hachée vous permet de vous positionner comme une organisation bien gérée et soucieuse de la sécurité, tandis qu'une base de données mal hachée est un embarras très public qui, comme l'histoire l'a montré à maintes reprises, va  ne  pas être ignoré ou négligé le moins du monde par les médias. "
 
 Si vous voulez être technique, vous pouvez hacher à nouveau ce qui précède. Mais si vous parlez à votre patron, vous devriez savoir mieux que cela. Et les analogies sont beaucoup moins efficaces que de simplement montrer les effets réels qui sont parfaitement visibles sans revêtement de sucre nécessaire. 
 
  Vous n'amenez pas les gens à porter des gants de sécurité en racontant une bonne analogie . Au lieu de cela, vous mettez de la viande de déjeuner dans le bécher et quand il explose dans des flammes vertes et bleues, vous dites: "C'est ce qui va arriver à votre doigt."  
 
 Utilisez le même principe ici. 

Ce fil de discussion est un peu court sur les analogies, alors voici:

Un mot de passe non haché est comme un verrou transparent, quiconque le regarde correctement peut concevoir la clé correspondante.

Pour commencer, je vais vous en fournir un pour commencer:

Imaginez que vous gérez une banque. Vous ne voulez pas permettre à vos clients d'accéder directement à l'argent. Vous avez donc un caissier qui n'a qu'un ordinateur et une petite somme d'argent pour gérer les retraits et les dépôts quotidiens. Il ne peut pas accéder à tout, ni transmettre de secrets au client, car il n’a pas accès à ces secrets.

Un caissier est très bien, mais parfois, vous avez une personne qui veut voler la banque et il ne va pas vraiment se faire arrêter par le caissier. Pour contrer cela, vous avez un très grand coffre-fort dans votre sous-sol qui contient tout l'argent réel de vos clients. ce coffre-fort a un tas de sécurité, comme un lecteur d'empreintes digitales, une reconnaissance vocale, des pressostats, des serrures à trois clés et une serrure à minuterie. il est conçu pour empêcher tous ceux qui ne devraient pas être là et qui ne savent pas comment passer la sécurité.

Ce coffre-fort arrêtera 99% des voleurs, mais il y a toujours ce 1% qui parvient à dépasser toute cette sécurité, soit en la contournant, soit en la brutalisant. Dans le cas où cela se produit, une banque stocke son argent dans des conteneurs piégés, qui rendent l'argent inutilisable, par des moyens comme le faire sauter ou pulvériser de la peinture partout. De cette façon, le voleur ne peut pas utiliser l'argent ou doit passer beaucoup de temps pour rendre l'argent à nouveau utilisable.

Une application logicielle possède également ces systèmes: le programme que l'utilisateur utilise est le guichetier: il ne peut pas lui faire faire ce qu'il veut à moins de trouver un moyen de le parler gentiment en coopération. la configuration matérielle et logicielle qui protège le programme et la base de données est le coffre-fort de la banque: il empêche les personnes qui ne savent pas quelles sont les faiblesses de la configuration de sécurité utilisée. Stocker le mot de passe en texte clair signifie que si quelqu'un dépasse le programme et la configuration de sécurité, il a libre accès aux mots de passe. Tout comme une banque stocke l'argent dans un conteneur qui rend l'accès à l'argent beaucoup plus difficile, le hachage du mot de passe donne à la personne qui compromet vos mots de passe un obstacle géant à franchir. Cela signifie également que les employés (à la fois la banque, les logiciels et ceux de notre propre entreprise) ne peuvent pas être poussés, contraints ou gentiment persuadés de contourner la sécurité d'un escroc, car même eux ne peuvent pas accéder directement à l'argent / aux mots de passe. Ils ne peuvent accéder qu'aux conteneurs / au hachage.

J'aime l'analogie comme moyen d'expliquer la technologie, mais dans ce cas, ce n'est probablement pas réalisable car l'analogie serait trop complexe.

La plupart des managers sont plus motivés pour éviter les risques personnels pour leur poste que de faire la bonne chose, donc plutôt que par analogie, j'utiliserais des exemples où le stockage de mots de passe en texte brut a eu un impact négatif sur une entreprise. Je dirais simplement quelque chose comme

"Stocker des mots de passe en texte brut nous donnerait une très mauvaise image, risquerait notre réputation et nous exposerait peut-être à des litiges. C'est considéré comme une très mauvaise pratique dans n'importe quel secteur, et là sont des sites Web consacrés à la dénomination et à la honte des entreprises qui stockent les mots de passe en clair. Personnellement, je n'aimerais pas être celui qui se tient devant le conseil d'administration / le patron / le CTO expliquant pourquoi nous n'avons pas mis en place un contrôle de sécurité de base. Si nous hachons les mots de passe de nos clients, une violation de données ne provoquerait pas une fuite immédiate de mots de passe que les pirates pourraient utiliser, et nous serions perçus comme protégeant les informations de nos clients. Le hachage des mots de passe atténue un gros risque pour peu d'efforts.

Incluez avec lui des liens vers Contrevenants en texte brut, puis envoyez des likes à certains articles tels que Cupid Media, Microsoft India Store, etc. .

Utiliser des analogies peut être puissant, mais dans ce cas, je pense qu'il serait beaucoup plus facile d'expliquer simplement dans un langage simple ce qui se passe. Quelque chose comme ça devrait être efficace, mais devrait probablement inclure des diapositives PowerPoint avec des illustrations et de grandes polices d'entreprise.

Comme vous le savez, nous demandons aux gens d'utiliser des mots de passe afin que nous sachions qui ils sont quand ils sont en utilisant notre produit. Nous devons garder une trace de ces mots de passe afin de permettre aux gens de se connecter. Le problème est que nous ne pouvons pas stocker les mots de passe exactement comme ils sont entrés, car les attaquants ont trouvé des moyens de les voir et de les voler.

Nous ne pouvons pas non plus simplement réécrire les mots de passe dans un code intelligent et croire que nous serons les seuls à savoir comment traduire le code, car cela ne garantit toujours pas que les attaquants déterminés ne peuvent pas comprendre le code, et il ne protège pas non plus contre les attaques de l'intérieur de notre organisation, comme les ex-employés voyous.

Pour résoudre ce problème, nous doit utiliser un hachage de mot de passe unidirectionnel . Un hachage de mot de passe, c'est comme utiliser un code, sauf qu'il est impossible de le décoder. * De cette façon, seul l'utilisateur connaît son mot de passe. Nous stockons uniquement le hachage du mot de passe et le vérifions lorsque l'utilisateur se connecte. Cela protège nos utilisateurs et réduit notre responsabilité en cas de violation de données, qui peut avoir de graves répercussions. [Incluez des exemples d'entreprises qui ont été poursuivies pour stockage non sécurisé des mots de passe]

* [Je sais que ce n'est pas impossible, mais le profane n'a probablement pas besoin de beaucoup détail.]

Toutes les explications à ce jour sont un peu longues, en voici une courte:

Certaines personnes qui ne se souviennent pas de leur NIP, gardent une note dans leur portefeuille.

Si un voleur ou une connaissance arrivait à regarder à l'intérieur du portefeuille, il aurait un problème, À MOINS QUE la broche ne soit écrite de manière à ce qu'elle ne puisse pas la lire.

Le hachage consiste essentiellement à écrire du texte d'une certaine manière que personne d'autre ne peut le lire.

Imaginez que vous êtes le videur d'un club. Pour savoir si vous souhaitez autoriser les gens à entrer, vous disposez d'un livre de codes contenant les noms / alias des personnes (certaines personnes préfèrent être discrètes et ne sont connues que de un alias) et leurs propres mots de passe privés; vous ne pouvez pas reconnaître que les gens sont ou ne sont pas ce qu'ils prétendent être par leur voix ou leur apparence (il y a trop de gens, et en raison des alias, les vérifications d'identité sont interdites), il vous suffit donc d'y aller hors du livre (le serveur Web ne peut pas dire en vous regardant que vous êtes la mauvaise personne) . Les gens doivent vous donner à la fois leur nom et leur mot de passe pour entrer, et s'il ne correspond pas à votre livre, ils sont refusés.

Si quelqu'un obtient une photo de votre livre de codes (votre base de données est divulguée) , ils peuvent usurper l'identité de qui ils veulent , sans que vous puissiez dire qu'ils mentent. Certains de vos clients utilisent également le même nom et le même mot de passe dans leur banque (qui ont des caissiers qui travaillent à partir de livres de codes comme vous), et se font ainsi voler de l'argent. Vous seriez alors renvoyé pour avoir permis une telle violation majeure, donnant une très mauvaise apparence au club et leur coûtant de l'argent.

Heureusement, vous pouvez acheter une boîte noire (fonction de hachage) qui prend leur nom (salt) et leur mot de passe et vous donne un long nombre aléatoire (hash) qui sera toujours le même pour un nom et un mot de passe donnés, et différent pour toute autre combinaison de nom et de mot de passe. Alors maintenant, au lieu de votre livre de codes contenant [nom et mot de passe], vous pouvez le faire contenir simplement [nom et numéro]! Lorsqu'une personne veut entrer, elle vous indique son nom et son mot de passe, vous les insérez dans votre boîte noire et vous recherchez son nom dans votre livre de codes pour vérifier que le numéro que votre boîte noire vous a donné correspond à celui enregistré.

Désormais, si quelqu'un obtient une photo de votre livre de codes, il ne pourra toujours pas y accéder! Il ne pourra même pas dire si la moitié de vos utilisateurs utilisent le même mot de passe, car chaque combinaison [nom et mot de passe] introduite dans la boîte noire était unique. Ils ont une boîte noire comme la vôtre, et peuvent ajouter un certain nom et des mots de passe aléatoires jusqu'à ce qu'ils trouvent le bon numéro, mais ils doivent le faire pour chaque personne individuellement.

Si vous découvrez que c'était fuite, vous devriez toujours demander à vos clients de changer leurs mots de passe pour une sécurité maximale, mais les attaquants n'auront pas la peine d'entrer.

Expliquez-le en termes de lignes de défense.

Évidemment, vous allez faire tout ce que vous pouvez pour vous assurer que votre code est sécurisé. Mais le fait est que votre serveur exécutera non seulement le code que vous avez écrit et que vous n'avez aucun contrôle sur le code écrit par d'autres personnes. Même si tous les autres codes de la machine sont open-source, vous devrez embaucher 2-3 autres développeurs à plein temps pour prendre la responsabilité de vos propres branches de tout. Puisque - ne nous leurrons pas - tout cela est censé être une mesure de réduction des coûts, ce n'est pas possible.

Ainsi, même si vous aviez une confiance absolue en votre propre code, il y aurait il reste encore beaucoup de place pour que les choses tournent mal. Vous avez donc besoin d'un moyen de vous assurer que même si un attaquant pénètre dans la machine, vos mots de passe sont toujours en sécurité. C'est là que le "hachage" (entre guillemets, car les algorithmes appropriés à utiliser à cette époque ne sont pas vraiment des algorithmes de hachage en soi, mais c'est toujours un terme fourre-tout utile) entre en jeu. .

En termes militaires, c'est essentiellement comment (et pourquoi) vous mettez en place plusieurs lignes de défense. Aucun général ne met l'ensemble de l'armée au même endroit, car vous devez tenir compte de la possibilité que quelque chose que vous n'aviez pas prévu permette à vos lignes de front d'être vaincues ou contournées. Le hachage est votre garde à domicile: la chose qui protégera vos mots de passe lorsque tout le reste a échoué. Vous espérez que cela ne sera jamais nécessaire, mais le coût de ne pas l'avoir lorsque vous en avez besoin est tout simplement trop élevé: des poursuites de plusieurs millions de dollars ne sont que le début.

Comment expliquer.

• Les humains sont des humains, peu importe leur modernisation; là, les mots de passe seront quelque chose comme la date de naissance ou le nom de la petite amie / petit ami / animaux de compagnie, etc.

Donc, il est dangereux d'enregistrer le mot de passe en texte clair. Tout le monde peut le lire.

• Le hachage aide à les rendre illisibles pour les humains (y compris pour un administrateur système fidèle).

Une fois qu'un mot de passe est haché, il est pratiquement impossible de récupérer. donc, il n'y a aucune crainte que votre mot de passe soit volé par quelqu'un. Même si quelqu'un obtient le hachage, il est inutile.

• Nous pouvons dire que si le mot de passe est un «fruit», alors le hachage sera «jus». donc, le jus suffit pour vérifier le mot de passe de l'utilisateur lorsqu'il essaie de se connecter.

L'inconvénient du hachage du mot de passe est : personne ne peut récupérer le passe originale. Dans un tel cas, le système doit demander à l'utilisateur d'entrer Nouveau mot de passe

.

1. Expliquez que les mots de passe sont volés tout le temps et que lorsque cela se produit, les entreprises sont VRAIMENT embarrassées et sujettes à des poursuites si les mots de passe sont en texte clair.
2. Expliquez que le hachage est vraiment facile à faire aujourd'hui.
3. Passons maintenant à l'analogie:

La meilleure analogie entre une fonction de hachage unidirectionnelle et des non-techniciens consiste simplement à utiliser une recherche numérique analogie - oubliez la cryptographie complexe. Lorsqu'un utilisateur vous donne à l'origine un mot de passe, vous attribuez un numéro unique au mot de passe à l'aide d'une boîte noire et vous stockez le numéro comme mot de passe de l'utilisateur au lieu du mot de passe d'origine.

Lorsque l'utilisateur vous redonne un mot de passe ultérieurement pour l'authentification, vous passez le mot de passe donné dans la boîte noire et récupérez un numéro. Vous pouvez maintenant comparer ce nombre avec le nombre que vous avez précédemment enregistré - si les deux nombres correspondent, les mots de passe sont les mêmes, si les deux nombres ne correspondent pas, les mots de passe ne sont pas les mêmes.

Chaque mot de passe unique passé dans la boîte reçoit son propre numéro unique, et chaque fois que le même mot de passe est passé dans la boîte noire, le même numéro sort.

La façon dont la boîte noire recherche le numéro est très connue , et tous les problèmes avec la boîte noire sont traités par l'industrie - toutes les vulnérabilités sont traitées par l'industrie - VOTRE entreprise n'est pas responsable s'il y a un problème avec la boîte noire.

Enfin, si le le numéro est volé dans la base de données de l'entreprise, la boîte noire bien comprise ne fonctionne pas à l'envers - vous ne pouvez pas prendre un numéro volé et récupérer le mot de passe (en supposant que le mot de passe d'origine était fort).

La réponse la plus fondamentale, que je n'ai encore vue personne dire directement, est que les actions de quiconque serait en mesure de découvrir un mot de passe ne peuvent pas être distinguées de manière fiable des actions de son propriétaire légitime. Si l'on veut être en mesure de prouver que le propriétaire légitime a effectué une action ou par sa propre action a exposé le mot de passe à une personne non autorisée, alors il faut s'assurer que le propriétaire légitime n'est jamais tenu de faire quoi que ce soit qui permettrait à quiconque de déterminer le mot de passe.

Si le mot de passe de Fred est stocké dans une base de données d'une manière qui n'est pas brouillée au-delà de la récupération, alors Fred pourrait contrer toute allégation d'actes répréhensibles en affirmant que son mot de passe peut avoir été utilisé ou divulgué par quelqu'un avec accès à la base de données de mots de passe. À moins que du matériel spécialisé ne soit utilisé pour stocker les mots de passe , il n'y aurait aucun moyen de réfuter la contre-réclamation de Fred.

Notez que pour une vraie sécurité, Fred ne devrait jamais exposer son mot de passe à autre chose que des équipements inviolables auxquels il a des raisons de se fier. Sinon, il y aurait un risque que l'équipement dans lequel Fred tape son mot de passe soit falsifié de manière à divulguer le mot de passe non haché à un adversaire.

Imaginez que vous êtes Scrooge McDuck. Vous gardez vos piles d'argent dans un coffre-fort géant depuis un certain temps maintenant, mais il y a un problème avec cela: si un voleur accède au coffre-fort, tout votre argent sera perdu en une seule fois! Ce n'est pas bon. Alors, canard intelligent que vous êtes, vous décidez de diviser votre argent en plusieurs piles plus petites et de mettre chacune dans son propre coffre-fort. Désormais, si le voleur accède à un coffre-fort, seule une petite partie de votre argent sera perdue et vous pouvez facilement remplacer le coffre-fort compromis. Bien mieux! Sauf que maintenant vous avez un nouveau problème: comment se souvenir des combinaisons de tous ces différents coffres? Vous ne pouvez pas simplement utiliser la même combinaison pour chacun, car si le voleur mettait la main dessus, il aurait accès à tout votre argent et vous ne seriez pas mieux loti que si vous l'aviez laissé dans un seul géant. pile!

Vous décidez de simplement noter toutes les combinaisons (ainsi que le coffre-fort dans lequel chacun va) sur un petit bout de papier, puis de mettre ce papier dans son propre coffre-fort séparé. Maintenant, vous n'avez plus qu'à vous souvenir d'une combinaison, mais votre argent est toujours séparé. C'est une amélioration, mais c'est toujours problématique, car si un voleur réussissait à trouver et à casser le coffre-fort contenant le papier, il serait toujours capable de prendre tout votre argent. Vous ne voulez pas que cela se produise!

Alors, que faites-vous? Eh bien, la solution idéale serait d'écrire les combinaisons dans une sorte de code. Vous voudriez un code qu'un voleur ne peut pas utiliser pour récupérer toutes les combinaisons originales, mais que vous pouvez toujours utiliser pour accéder à votre argent. Malheureusement, il n'y a pas vraiment de moyen de le faire pour de l'argent dans des coffres. Heureusement, cela est possible pour les comptes d'utilisateurs protégés par mot de passe, car nous n'avons pas vraiment besoin de connaître les mots de passe de nos utilisateurs - nous avons seulement besoin de savoir que ils les connaissent.

Garder votre argent dans un coffre-fort géant, c'est comme avoir un seul mot de passe principal pour tout votre système. Conserver de l'argent dans différents coffres-forts et noter toutes les combinaisons, c'est comme garder les données de vos utilisateurs séparées dans des comptes protégés par mot de passe, mais ensuite garder tous leurs mots de passe en texte clair à un seul endroit: tant qu'un attaquant sait ou peut deviner où cet emplacement c'est que ce n'est pas vraiment différent d'avoir un seul mot de passe principal. Vous avez besoin d'un moyen d'encoder votre liste de mots de passe de manière à pouvoir continuer à l'utiliser pour vérifier qu'un utilisateur possède le mot de passe correct , tout en vous assurant que un attaquant ne peut pas utiliser le list pour récupérer les mots de passe eux-mêmes . En un mot, c'est ce que fait le hachage.

Supposons que votre base de données contenant des mots de passe soit divulguée ou volée:

Si les mots de passe sont en texte brut, tous vos mots de passe nous appartiennent.

Si les mots de passe sont hachés, tous les mots de passe sont toujours dans un coffre-fort partagé qui doit être piraté.

Si les mots de passe sont hachés et salés, chaque mot de passe est dans son propre coffre-fort privé.

Heure de l'analogie:

1. Stocker des mots de passe en clair, c'est comme laisser votre maison déverrouillée.
2. Crypter la base de données de mots de passe revient à stocker la clé sous le paillasson.
3. Le hachage des mots de passe revient à utiliser un verrou numérique à 3 chiffres partagé par tous les utilisateurs.
4. Le salage des hachages de mot de passe donne à chaque utilisateur son propre verrou numérique.
5. PBKDF donne ces verrous numériques plus de chiffres.

Personne ne devrait en fait décider des questions de sécurité en se basant sur une analogie, mais cela pourrait aider à expliquer à un profane pourquoi il est important de prendre des précautions.

Pour les fonctions de hachage, aucune analogie toute faite ne se trouve dans le domaine du football ou de l'automobile. Le mieux que nous puissions faire est de révéler les faits réels.

Cher patron,

Dans un monde parfait, les utilisateurs seraient soucieux de la sécurité et n'utiliseraient jamais le même (ou même un ) mot de passe pour au moins deux sites ou services différents. Dans ce monde parfait, un mot de passe aurait peu de valeur pour un attaquant. Après avoir compromis la base de données des utilisateurs et appris les mots de passe, ces mots de passe ne seraient pas utiles pour accéder à d'autres systèmes.

Dans le monde réel, les utilisateurs réutilisent les mots de passe, et donc le secret des mots de passe doit continuer à être protégé même lorsqu'un système a été violé, afin de limiter les dégâts.

Le hachage aide à protéger les mots de passe, car le seul moyen d'obtenir un mot de passe à partir du hachage est un calcul par force brute qui prend du temps. Ce calcul cassera d'abord les mots de passe faibles qui sont courts ou basés sur des mots du dictionnaire et des phrases courantes. Il faut beaucoup plus de temps pour casser les mots de passe forts, mais avec suffisamment de temps, ceux-ci tomberont aussi.

Cependant, comme il faut du temps pour déchiffrer les mots de passe hachés, les utilisateurs du système compromis ont tendance à réutiliser les mots de passe, ou utiliser des mots de passe similaires, auront peut-être assez de temps pour être averti et pour changer leurs mots de passe sur d'autres systèmes, avant que l'attaquant tente d'accéder à leurs comptes. (Ceux qui ont des mots de passe très faibles n'auront que peu ou pas de temps, malheureusement, car les mots de passe faibles peuvent "craquer" très rapidement à partir des hachages. > Sans hachage, l'attaquant peut immédiatement accéder à d'autres systèmes après avoir volé les mots de passe du système compromis. Au moment où les administrateurs ont même appris l'existence de la violation, d'autres systèmes ont déjà été consultés, du moins pour les utilisateurs qui réutilisent les mots de passe.

Il y a une deuxième menace: celle de l'accès clandestin. Cela affecte même les utilisateurs qui ne réutilisent pas les mots de passe. Supposons que la base de données de mots de passe d'un système soit divulguée, mais que cet événement ne soit pas détecté. L'attaquant peut utiliser les mots de passe pour accéder subrepticement au système pendant des mois ou des années après la violation. Non seulement l'attaquant a volé des informations qui étaient à jour au moment de l'incident, mais il peut continuer à voler des informations simplement en se connectant aux comptes pour lesquels il a des mots de passe, tant que ces mots de passe ne changent pas.

Les mots de passe hachés aident à se prémunir contre cette menace, en particulier lorsqu'ils sont associés à une politique de changements de mot de passe réguliers et de mots de passe forts. Les mots de passe hachés qui sont forts garantissent que l'attaquant doit effectuer un long calcul afin de découvrir un mot de passe à partir du hachage. La politique de changement de mot de passe permet de garantir qu'au moment où ce calcul est effectué, le mot de passe découvert est probablement inutile car il a été modifié.

Analogie: en tant que serrurier, je peux (avec la permission des clients) conserver des enregistrements de ce que j'ai fait pour eux, y compris les détails de leurs clés. Mais cela me met en danger de voir ma propre boutique cambriolée et la liste volée (ou un employé maléfique le faisant) - auquel cas l'escroc pourrait fabriquer les clés de nombreuses maisons, et je serais responsable de ne pas l'avoir protégé. les informations.

La solution pour les clés est de NE JAMAIS stocker leurs informations clés en texte clair. Stockez-le crypté et n'écrivez jamais les informations nécessaires pour décoder ces données. Si quelqu'un vole la liste chiffrée, il ne peut pas faire de dégâts avec elle.

Bien sûr, pour un ordinateur, "ne jamais écrire" signifierait qu'il ne pourrait pas décoder les mots de passe. Mais nous pouvons résoudre ce problème en créant un système où nous n'avons pas à les décoder. Au lieu de cela, nous prenons le mot de passe saisi par l'utilisateur, l'encodons et comparons la version encodée avec le mot de passe encodé que nous avons stocké. S'ils correspondent, l'utilisateur a tapé le bon mot de passe. Il y a des "codes" (hachages cryptographiques) qui permettent le codage mais pas le décodage, donc cela peut être rendu respectablement sécurisé.

Les listes de mots de passe hachés peuvent encore parfois être fissurées, mais c'est TRÈS plus cher de le faire - - et tout aussi important, vous pouvez montrer que vous avez fait un effort raisonnable pour protéger les données des utilisateurs, donc votre responsabilité est bien moindre.

L'importance technique du hachage est largement surestimée.

La raison pratique pour laquelle vous avez besoin de hacher est que tout le monde le fait; elle est considérée comme une «meilleure pratique». Si vous avez une brèche, il est beaucoup plus facile de défendre une position où vous faites la même chose que vos pairs. Faire quelque chose de différent, même si c'est la bonne chose, est beaucoup plus difficile à défendre. Je conseille donc toujours aux sites Web de suivre la méthode de hachage standard, même si je pense que c'est de la bêtise.

Alors pourquoi l'importance du hachage est-elle largement surestimée? Commençons par penser à un site Web avec des mots de passe non hachés. Les mots de passe seraient stockés en texte brut dans la base de données. La base de données est sécurisée - sur un serveur physiquement sécurisé, cryptage complet du disque, pare-feu, administration sécurisée et elle est protégée par la logique d'application sur le serveur Web. Ces mots de passe sont fondamentalement sécurisés.

Pourquoi faisons-nous du hachage? Il fournit une dernière ligne de défense. Supposons que toutes ces défenses soient contrecarrées. Peut-être que la NSA a utilisé un exploit de navigateur zero-day pour obtenir des logiciels malveillants sur le poste de travail de l'administrateur système, a attendu qu'il se connecte à la base de données, puis a pris le contrôle à distance et extrait toutes les données. Dans ce cas, la NSA obtient tous les mots de passe en clair. Et c'est là que le hachage aide: si vous utilisez le hachage, la NSA n'obtient que les hachages, et ils devraient mener une attaque par force brute pour obtenir les mots de passe.

Et c'est pourquoi les gens recommandent le hachage. Mais ceci est défectueux pour trois raisons:

1. Données personnelles - le site Web contient vos mots de passe, et il contient également des données personnelles. Qu'il s'agisse de messages, de photos, d'historique d'achat. La raison pour laquelle vous avez un mot de passe en premier lieu est de protéger vos données personnelles. Le hachage peut protéger le mot de passe, mais il ne protège en rien vos données personnelles.

2. Capture en direct - bien qu'il n'y ait que des hachages stockés dans la base de données, chaque fois que quelqu'un se connecte, son mot de passe est envoyé au serveur Web. La NSA peut silencieusement s'asseoir sur le serveur pour capturer le mot de passe de tout le monde. Le hachage ne fait rien pour empêcher cela.

3. Réutilisation du mot de passe - Il est important d'éviter la réutilisation du mot de passe pour d'autres raisons. Ainsi, lorsque LinkedIn est piraté, peu importe qu'ils obtiennent mon mot de passe ou non. Les hackers ont déjà mes données personnelles de LinkedIn. Et s'ils récupèrent mon mot de passe, cela leur donne accès uniquement à LinkedIn, et ils ont déjà ces données.

Compte tenu de tout cela, les avantages du hachage de mot de passe sont marginaux. Je ne sais pas pourquoi la communauté InfoSec continue de parler de hachage de mot de passe, il serait bien plus judicieux de se concentrer sur la prévention des violations de bases de données en premier lieu. En général, les coûts de hachage sont relativement faibles, mais il y a une exception: les hachages fortement itérés. Le coût technique est élevé et les avantages sont faibles, ce conseil est donc assez mal interprété. Néanmoins, je dois conseiller aux gens de le suivre, car il s’agit de «bonnes pratiques».

Que dire au patron: "Voici le problème. Je suis un développeur de logiciels expérimenté et je vous dis que stocker un mot de passe non chiffré est risqué à un niveau de stupidité inexcusable absolue. Même stocker des mots de passe non salés est risqué sur le plan d'incompétence flagrante. Et je viens de vous dire ceci. Vous pouvez m'ordonner de stocker des mots de passe non chiffrés, et je le ferai, mais si jamais nous rencontrons des problèmes, je dirai à quiconque veut entendre que ce n'est pas parce que je suis incompétent , mais parce que vous m'avez ordonné de le faire contre un avis sérieux. À ce stade, je vous promets que vous serez tenu personnellement responsable et que vous aurez des avocats après vous qui voudront chaque centime que vous personnellement posséder.