Les utilisateurs utilisent souvent les mêmes mots de passe sur plusieurs sites. Votre site ne contient peut-être pas de données financières, mais que se passe-t-il si le même mot de passe est utilisé pour leur banque ou pour une boutique en ligne?

Vous pourriez affirmer que ce n'est pas votre problème, mais c'est un problème courant problème, et c'est pourquoi chaque fois qu'une violation se produit, l'une des déclarations immédiates est "changez votre mot de passe et changez-le sur tous les autres sites où vous avez utilisé le même mot de passe".

Si votre site a utilisé quelque chose comme Bcrypt (sans faille dans l'implémentation - voir Ashley Madison), les chances d'un attaquant de pouvoir déterminer quels mots de passe ont été utilisés sont plus minces, et cela augmente le temps pour les utilisateurs de pouvoir changer leurs mots de passe ailleurs. Si vous stockez simplement le mot de passe dans votre base de données sans aucun hachage, un attaquant peut s'éloigner avec les adresses e-mail et les mots de passe et commencer à attaquer immédiatement un autre site.

Les paires d'adresses e-mail et de mots de passe sont souvent échangées entre les attaquants également, sous la forme de "listes combinées", ce qui signifie que même si l'attaquant d'origine n'est intéressé que par votre site, il pourrait être en mesure d'obtenir un certain avantage en vendant les données à quelqu'un d'autre.

Ajouté en réponse au commentaire sur la question mentionnant le stockage chiffré à 2 voies

Le problème avec une approche de chiffrement à 2 voies est que les informations à déchiffrer doivent être stockées quelque part dans le système. Si un attaquant accède à votre base de données, il y a de fortes chances qu'il ait également accès à votre clé de chiffrement. Un hachage ne peut pas être inversé de cette manière - les outils en ligne pour inverser les hachages recherchent efficacement le hachage dans une liste précalculée.

Même s'ils n'ont pas la clé de chiffrement, ils pourraient être en mesure pour déterminer quelle était la clé - ils peuvent utiliser une attaque connue en texte clair en entrant un mot de passe dans votre système et en voyant le résultat. Ce ne serait probablement pas un processus rapide, mais cela pourrait valoir la peine de le faire s'il y avait des cibles de grande valeur dans vos données (célébrités, politiciens ...).

D'un autre côté, avec un hachage fort et salé, la seule façon de trouver le mot de passe d'origine avec une forte certitude est de hacher toutes les entrées possibles, en utilisant le sel approprié. Avec quelque chose comme Bcrypt, cela prendrait des années, même si les mots de passe faibles seront toujours trouvés relativement rapidement.

Bonne question, et je suis content que vous l'ayez posée. Je veux que les gens trouvent ce fil de discussion lorsqu'ils le recherchent sur Google afin qu'ils ne fassent pas, espérons-le, les mêmes erreurs que de nombreuses autres entreprises.

Vous ne devriez pas simplement hash mots de passe, vous devez les saler et vous assurer que votre algorithme de hachage utilise une forme de SlowEquals . Vous ne devriez pas vous arrêter là: vous devriez utiliser un algorithme de hachage sécurisé qui résiste énormément aux collisions , comme bcrypt ou scrypt.

Pourquoi sel? Que sont les collisions?

Je vais utiliser md5 comme exemple car il est très connu. Ne l'utilisez pas, car il est vulnérable aux collisions et est très rapide , ce qui signifie qu'il est beaucoup plus facile à casser. Imaginons que vous hachiez simplement vos mots de passe sans sel. Vous finiriez par produire une sortie statique à peu près à chaque fois.

Par exemple, " myDarnPassword " finirait par être converti en " aca6716b8b6e7f0afa47e283053e08d9 " lorsqu'il était haché en md5. À ce stade, vous pouvez créer une attaque par dictionnaire et utiliser des tables arc-en-ciel. Vous pouvez même générer une base de données qui convertit autant de caractères aléatoires en une base de données facilement consultable qui ne nécessitera pas de longues recherches dans les tables arc-en-ciel. Vous pouvez créer cela lentement au fil du temps et rechercher des hachages plus tard.

Vous créeriez une table ressemblant à ceci:

  + --------- ---------- + ---------------------------------- + | PASSWORD | UNSALTED_HASH | + ------------------- + --------------------------- ------- + | myDarnPassword | aca6716b8b6e7f0afa47e283053e08d9 | + ------------------- + --------------------------- ------- + | pleaseDontSueMe11 | 0dd395d0ec612905bed27020fb29f8d3 | + ------------------- + --------------------------- ------- +  

Ensuite, vous choisiriez dans la base de données un peu comme ceci:

  SELECT [mot de passe] FROM [table] WHERE [ unsalted_hash] = 'aca6716b8b6e7f0afa47e283053e08d9'  

Et il renverrait myDarnPassword , plus toutes les collisions survenues.

Avec suffisamment de puissance de traitement et de temps, vous pouvez créer des milliards de combinaisons et casser assez facilement un grand nombre de mots de passe en très peu de temps (je pourrais recommander de diviser les bases de données en longueurs de mot de passe en raison du nombre ). Cependant, vous auriez besoin d'une quantité colossale d'espace disque dur pour cela.

À ce stade, tout ce que vous avez vraiment à faire est de le rechercher sans perdre de puissance de traitement à tout forcer à chaque fois. Et si vous avez déjà volé les mots de passe d'autres personnes dans une base de données, vous pouvez les ajouter et les convertir en hachages. De nombreux sites Web l'ont déjà fait.

Lorsqu'un site Web valide votre mot de passe, il compare le mot de passe au hachage stocké, et s'il correspond au hachage de la base de données, il est considéré comme un mot de passe valide. Vous pouvez alors autoriser l'utilisateur à se connecter.

Saler le hachage peut aider à vaincre cette attaque, mais cela ne vous sauvera pas des collisions. Vous pouvez comparer les hachages piratés à votre liste de hachage qui a généré des collisions, puis saisir ce mot de passe sur un site Web, même si vous avez le mauvais mot de passe: tant que le hachage est validé, vous êtes pwned .

Qui se soucie si quelqu'un déchiffre mes mots de passe? Je m'en fiche!

Voici juste une petite collection d'exemples de ce que les hameçonneurs et autres individus malveillants pourraient avec vos mots de passe en texte brut non hachés et non salés. Il peut ne pas être nécessairement utilisé pour vous cibler directement, mais disons que Hacker veut cibler Personne A . Déduisons comment vous pouvez cibler Personne A .

1. Vous êtes Hacker . Votre travail consiste à pirater des sites Web et à développer une base de données pour agréger ces informations.
2. Personne A est une personne d'intérêt. Personne A apparaît dans l'une de vos bases de données de sites piratés. Vous connaissez maintenant leur adresse e-mail et le mot de passe qu'ils utilisent pour ce site Web.
3. Vous pouvez maintenant essayer de vous connecter à leur adresse e-mail avec le mot de passe que vous avez volé sur ce site Web. Doux, ça marche!
4. Maintenant que vous avez accès à leur messagerie, vous téléchargez tous leurs e-mails via IMAP , ou via leur messagerie Web. À ce stade, vous trouvez beaucoup de choses intéressantes. Ils communiquent avec Personne B .
5. Vous pouvez en fait google les noms d'utilisateur et les adresses e-mail de certaines personnes, et cela pourrait afficher les sites Web sur lesquels ils publient. Cela fera apparaître d'autres sites Web que l'utilisateur utilise. Peut-être que vous pouvez essayer de pirater ces sites Web, ou peut-être que vous pouvez simplement en déduire ce qu'ils recherchent. Vous pouvez désormais faire semblant d’être comme eux ou trouver des informations supplémentaires. Les informations / activités peuvent inclure:
   • Noms d'utilisateur . La personne A publie en ligne sous le nom de Mark Buffalo . C'est un nom relativement unique. Vous pouvez ensuite rechercher sur Google Mark Buffalo et rechercher les sites Web sur lesquels il publie. Peut-être révèle-t-il davantage sa personnalité sur d'autres sites?
   • Mots de passe . Peut-être que Mark Buffalo a le même mot de passe sur ce site Web. Peut-être pouvez-vous vous connecter à ce site Web et consulter ses communications privées avec d'autres personnes?
   • Informations personnelles . Puisque vous connaissez l'identité de Mark Buffalo , que se passe-t-il s'il partage des informations personnelles sur certains sites Web? Et s'il publie sur Craigslist à la recherche d'escortes masculines ou féminines et qu'il y laisse son numéro de téléphone? Vous avez déjà trouvé ses informations de téléphone, vous pouvez donc trouver un moyen de le configurer et de le faire chanter pour de l'argent / des informations / du pouvoir. Cela n'a pas grand-chose à voir avec le salage des mots de passe à moins que vous n'incluiez le numéro de téléphone, mais ils trouvent leur numéro de téléphone sur un autre site Web grâce à votre fuite. C'est l'un des nombreux moyens très puissants dont les informations peuvent être collectées et utilisées contre vous. Il s'agit, après tout, d'un forum Sécurité de l'information , je souhaite donc utiliser cet exemple.
   • Informations familiales . Maintenant, ça devient effrayant. Nous avons les informations personnelles de Mark Buffalo. Regardons ses réseaux sociaux. Oh, il a un compte Facebook (je n'en ai pas). Pouvons-nous y accéder avec le même mot de passe? Si Buffalo utilise la même combinaison mot de passe / e-mail, alors probablement. Et vous pouvez probablement le déduire de son email auquel vous avez accédé plus tôt, où vous avez trouvé beaucoup de choses intéressantes. Nous pouvons maintenant nous connecter et lire ses messages Facebook. Maintenant, nous savons qui sont les membres de sa famille. Nous pouvons alors coordonner plus facilement l'attaque de chantage.
   • Autres informations de connexion . Depuis que nous avons eu accès à son email plus tôt, nous voyons qu'il a également un compte Skype. L'un d'eux est secret. Nous nous connectons et voyons qu'il flirte avec des gens sur Skype. Nous avons maintenant plus de matériel de chantage.
   • Usurpation d'identité . Vous pouvez maintenant vous connecter et vous faire passer pour Buffalo sur une variété de sites Web. Peut-être qu'il est en fait un simple tireur et qu'il n'a jamais recherché une escorte, ou quoi que ce soit du genre? Eh bien, vous pouvez maintenant le transformer en un réprouvé à la recherche d'une escorte, du moins en apparence, en utilisant ses informations d'identification pour se faire passer pour lui en ligne. Imaginez les dommages que pourrait causer un politicien qui a été accusé à tort et contraint de démissionner.
   • Ce qui facilite le piratage d’autres personnes . Vous pouvez ensuite envoyer des e-mails à la Personne B avec des pièces jointes infectées et faire semblant de le connaître. Vous avez lu suffisamment de courriels, vous êtes donc capable d'imiter Mark Buffalo au point où vous lui ressemblez. Vous rédigez l'e-mail d'une manière qui laisse la Personne B sans méfiance de ce qui se passe réellement, et maintenant vous pouvez faire la même chose à Personne B , ou pire.

Et ce n'est qu'une petite collection d'idées. Il existe de nombreuses utilisations différentes des informations d'identification de quelqu'un d'autre. Saler et hacher vos mots de passe, utiliser des algorithmes de hachage résistants aux collisions tels que bcrypt et scrypt, et prévenir les attaques par injection SQL. S'il vous plaît, ne me transformez pas en un réprouvé à la recherche d'escorte! Sauvez Mark Buffalo!

(Je sais que certains sites Web peuvent bloquer votre tentative d'accéder à leurs services lorsque vous utilisez une adresse IP différente, mais il existe de nombreuses façons de contourner ce problème, et tous les sites Web ne le font pas) .

Au fait, félicitations pour votre éventuel recours collectif si vous êtes piraté.

Un type commun de violation est l'accès en lecture seule à la table des utilisateurs. En effet, cette table est utilisée dans le code qui effectue la connexion pour laquelle vous n'avez pas besoin d'être déjà authentifié. Obtenir les mots de passe permettrait alors un accès en lecture à toutes les données, mais même si l'attaquant a déjà un accès en lecture complet sur la base de données, il peut toujours obtenir un accès en écriture via les mots de passe, en étant capable de se connecter au compte et de modifier facilement certaines données.

Une raison très simple pour saler et hacher les mots de passe des utilisateurs est la suivante:

Le mot de passe d'un utilisateur est son secret

Personne d'autre ne devrait le savoir. Ni vous, ni votre collègue, ni le DBA. Personne . Aussi simple que ça ...

Une partie du salage consiste à rendre plus difficile l'analyse et le vol du mot de passe et l'utilisation de leur combinaison nom d'utilisateur / e-mail et mot de passe sur d'autres sites.

Il est assez courant pour les utilisateurs de réutiliser 1 ou 2 mots de passe sur plusieurs sites. Changer votre algorithme en un algorithme qui sale et prend un peu plus de temps (par exemple bcrypt, scrypt et similaire) est fortement recommandé et assez simple à implémenter dans la plupart des langages.

Le but d'un salt est double: premièrement, il introduit un élément unique (-ish) dans chaque mot de passe, de sorte que si deux utilisateurs utilisent le même mot de passe, le texte haché du mot de passe variera. Si l'utilisateur A voit que son hachage de mot de passe est "QWERTYU123", et que le hachage de mot de passe de l'utilisateur B est également "QUERTYU123", alors l'utilisateur A peut déduire qu'il a le même mot de passe que l'utilisateur B.

Deuxièmement, il introduit un ralentisseur significatif pour toute personne ayant accès à la base de données qui souhaite forcer brutalement les mots de passe avec une attaque par dictionnaire. Sans sel, l'attaquant peut simplement hacher "TRUSTNO1" pour obtenir le hachage "QUERTYU123", puis parcourir la colonne du mot de passe pour voir si ce texte apparaît. Avec un sel, l'attaquant doit répéter "TRUSTNO1" pour chaque ligne de la base de données afin de tester une correspondance, ce qui augmente considérablement la quantité de CPU requise pour vérifier chaque entrée du dictionnaire.

s'ils ont accès à la base de données, ils n'ont pas réellement besoin du ou des mots de passe car ils peuvent simplement voler les données directement de la base de données

Le mot de passe est la chose précieuse. C'est parce que beaucoup de gens réutilisent le même mot de passe. Ainsi, le mot de passe de votre pigeonnier pourrait être le même que celui utilisé pour leurs services bancaires en ligne.

Je m'occupe d'un système qui contient beaucoup d'informations de "bas niveau", rien de financier mais le nom / adresse / e-mail etc.

Ceux-ci sont également précieux. J'ai perdu la trace du nombre d'e-mails que j'ai reçus récemment de «eBay» ou «Apple» affirmant que mon compte a été limité à moins que je «vérifie» mes coordonnées. Ils sont généralement manifestement faux car ils ne mentionnent pas mon vrai nom. Mais si vous stockez un nom et une adresse e-mail, il est beaucoup plus facile de faire un mail-out réaliste, en demandant plus d'informations personnelles. Par exemple:

Cher M. Smith du 42 Station Street, Gotham City.

Nous venons de réaliser que notre club vous a surfacturé cet exercice et aimerions vous rembourser 10 $. Veuillez répondre avec vos coordonnées bancaires afin que nous puissions déposer l'argent sur votre compte.

Donc, ne rejetez pas les e-mails et les noms.

Le bas La ligne est, cependant, que le hachage et le salage de votre base de données existante ne devraient prendre qu'environ une heure de codage et de test. Ensuite, vous pouvez effectuer une "conversion par lots" des mots de passe en texte brut en mots hachés et salés.

Le cryptage des informations utilisateur comme le nom, l'e-mail, etc. et le stockage dans la base de données plutôt que de le stocker au format brut offre un niveau de sécurité supplémentaire à votre application. Deuxièmement, les personnes ayant accès à votre base de données ne peuvent pas non plus lire facilement les données. Tout type d'informations que vous stockez et qui proviennent de n'importe quel client a son secret. Comme il s'agit de leurs données et qu'il incombe aux développeurs de les stocker de manière à ce qu'il soit difficile pour le piratage de donner un sens, qu'il s'agisse d'informations de faible qualité ou d'informations top secrètes. En outre, le décryptage et le cryptage des données doivent être effectués côté serveur car généralement les serveurs sont conservés derrière un pare-feu. Cela devient donc plus sûr du point de vue de la sécurité.

Je peux voir ce que vous voulez dire si l'attaquant pouvait également accéder à la base de données. Le fait est qu'un système de sécurité bien conçu ne permettra à la base de données de stocker que les informations que l'utilisateur et le serveur ont cryptées individuellement.

En général, le mot de passe est la première voie de valeurs cachées dans laquelle vous pouvez demander à vos utilisateurs de donner qui peuvent être hachées pour déchiffrer leurs données afin de fournir une deuxième couche de sécurité si les clés de chiffrement de la base de données sont compromis. De cette façon, même en cas de violation, les données de l'utilisateur sont toujours en sécurité.

Dans ce contexte, le point de hachage est basé sur l'idée d'une fonction à sens unique, ou trappe, une fonction facile à calculer mais difficile à inverser. Lorsque l'utilisateur génère un mot de passe, le système calcule son hachage et stocke cette valeur dans la base de données. Lorsque l'utilisateur soumet un mot de passe pour accéder au système, il calcule son hachage et le compare à la valeur de la base de données. S'ils sont les mêmes, tant mieux; sinon, le mot de passe est erroné et l'utilisateur doit être empêché d'accéder au système. Afin de faire ce travail, le hachage a besoin de deux propriétés: (1) Différentes valeurs d'origine hachées à des valeurs différentes; (2) Il est difficile en calcul de passer du hachage à la valeur d'origine.

Alors, pourquoi s'embêter avec des hachages? Si quelqu'un pirate votre base de données (pas seulement par piratage informatique, mais par des attaques d'ingénierie sociale, en laissant une impression dans le bus, par les actes d'un employé mécontent, etc.), tout ce qu'ils obtiennent est une série de valeurs de hachage. Il est difficile de récupérer la valeur d'origine à partir d'une valeur de hachage, ce n'est donc pas très utile pour un hacker. Si les mots de passe en clair sont stockés dans la base de données, le pirate gagne si la base de données est compromise; il a un accès direct à tous les comptes et mots de passe, et il peut pratiquement faire ce qu'il veut. Cette configuration signifie également que vous n’avez pas accès aux mots de passe des utilisateurs. C'est une bonne chose; même si vous vous faites confiance, vous n'avez probablement pas confiance - et ne devriez pas avoir besoin de faire confiance - à votre homologue de votre banque, à votre prédécesseur ou successeur au travail, etc. Vous ne devriez pas avoir à dépendre des largesses ou caprice d'un administrateur afin de garantir la sécurité de vos informations.

En ce qui concerne les sels, j'ai mentionné ci-dessus que les hachages doivent avoir deux propriétés non triviales pour être efficaces. (Il y en a d'autres que je saute pour le moment.) Les fonctions ayant ces propriétés ne sont pas triviales à trouver, et il serait imprudent de compter sur l'administrateur particulier d'un site pour en trouver un décent. Au lieu de cela, il existe des hachages largement disponibles que la plupart des gens utilisent. Le but d'un sel est de s'assurer que différents sites utilisent efficacement différents hachages: au lieu de simplement hacher «mot de passe», nous avons plutôt «sel» + «mot de passe» pour différentes valeurs de «sel». Cela signifie que si quelqu'un utilise le même mot de passe sur deux sites, il a en fait des hachages différents sur les deux systèmes, de sorte qu'un pirate ne peut pas utiliser l'un pour casser l'autre. De plus, sans le sel, les pirates pourraient simplement forcer brutalement tous les hachages pour des mots de passe d'une longueur raisonnable. J'ai mentionné ci-dessus que les hachages doivent être difficiles à inverser. Si vous avez un tableau de tous les hachages possibles pour les mots de passe jusqu'à, disons, 10 lettres (ou même simplement les mots de passe les plus couramment utilisés), alors il est trivial d'inverser le hachage; regardez-le simplement dans le tableau.

En plus des autres réponses, gardez à l'esprit qu'il existe de nombreux degrés de vulnérabilités entre un accès totalement sécurisé et un accès complet à une base de données. Une vulnérabilité peut exposer uniquement certains mots de passe, ou seulement les premiers caractères de celui-ci, ou être difficile à associer à un utilisateur particulier, etc. > De plus, les intrus aiment limiter leur propre exposition. Plus ils utilisent une vulnérabilité ou une porte dérobée pour entrer dans un système, plus ils sont susceptibles d'être découverts et verrouillés avant d'atteindre leur objectif. Si vous laissez vos mots de passe non hachés et non salés, vous venez de leur donner un moyen très simple de revenir dans le système en se faisant passer pour n'importe quel utilisateur, ce qui est extrêmement difficile à détecter et à atténuer.

Je pense que la meilleure façon d'exprimer cela est: l'année est 2015, les informations les plus privées et personnelles que vos utilisateurs vous confient sont leur mot de passe et leur identifiant. Protégez-le, non pas avec votre vie mais avec votre ignorance, pas avec votre capacité, mais votre incapacité.

Si vous ne connaissez pas leur mot de passe et n'avez aucun moyen de récupérer leur mot de passe, alors personne ne peut le voler de vous ou de vous forcer à le divulguer.

Tout voleur numérique compétent, ayant le choix entre un tel nom et adresse et mille adresses e-mail / noms d'utilisateur et mots de passe, prendra le plus tard à chaque fois. >

Je comprends le coût et le temps, mais si cela est fait correctement, dès le début, cela ne prend vraiment pas du tout de temps supplémentaire, et le passage à une méthode plus sécurisée n'est pas ça prend du temps.