Existe-t-il une réelle valeur dans le hachage / salage des mots de passe?

Question

Je m'occupe d'un système qui contient beaucoup d'informations de "faible qualité", rien de financier, mais un nom/une adresse/un e-mail, etc. J'ai fait un peu de lecture et j'ai du mal à en voir les avantages, mon argument est revenu aux "experts" qui le suggèrent mais ils (ne peuvent) pas répondre à ma question assez simple.

Pour autant que je sache, le hachage/salage empêche le mot de passe d'être lu et décrypté par un pirate, et c'est excellent pour cela, aucun argument. Mais à moins que je manque quelque chose, pour lire la valeur du mot de passe, le pirate doit avoir accès à la base de données afin qu'il puisse voler les valeurs du mot de passe? ... s'il a accès à la base de données, il n'a pas réellement besoin de la mot de passe car ils peuvent simplement voler les données directement de la base de données, c'est-à-dire que l'accès aux applications qu'ils obtiennent des mots de passe ne leur donnerait rien de plus que de lire la base de données directement?.

Qu'est-ce que je rate?

Matthew · Answer

Les utilisateurs utilisent souvent les mêmes mots de passe sur plusieurs sites. Votre site peut ne pas avoir 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 faire valoir que ce n'est pas votre problème, mais c'est un problème commun, 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 défauts d'implémentation - voir Ashley Madison), les chances qu'un attaquant puisse déterminer quels mots de passe ont été utilisés sont plus minces, et cela augmente le temps pour les utilisateurs de pouvoir changer leur mots de passe ailleurs. Si vous venez de stocker le mot de passe dans votre base de données sans aucun hachage, un attaquant peut se promener avec les adresses e-mail et les mots de passe et commencer à attaquer un autre site immédiatement.

Les paires d'adresses e-mail et de mots de passe sont également souvent échangées entre des attaquants, 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 des avantages en vendant les données à quelqu'un. autre.

Ajouté en réponse au commentaire sur la question mentionnant le stockage crypté bidirectionnel

Le problème avec une approche de cryptage bidirectionnelle est que les informations à décrypter 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 ne disposent pas de la clé de cryptage, ils pourraient être en mesure de déterminer quelle était la clé - ils peuvent utiliser une attaque connue en texte brut en entrant un mot de passe sur votre système et en voyant le résultat. Ce ne serait probablement pas un processus rapide, mais cela pourrait valoir la peine 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, bien que les mots de passe faibles soient toujours trouvés assez rapidement.

Mark Buffalo · Answer

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

Vous ne devez pas seulement hash mots de passe, vous devez salt les et assurez-vous que votre algorithme de hachage utilise une certaine forme de SlowEquals. Vous ne devriez pas vous arrêter là: vous devez utiliser un algorithme de hachage sécurisé qui résiste à collisions, comme bcrypt ou scrypt.

Pourquoi du 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 est haché en tant que md5. À ce stade, vous pouvez créer une attaque par dictionnaire et utiliser des tables Rainbow. 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 beaucoup de temps Rainbow Vous pouvez créer cela lentement au fil du temps et rechercher des hachages plus tard.

Vous créez un tableau qui ressemble à ceci:

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

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

SELECT [password] FROM [table] WHERE [unsalted_hash] = 'aca6716b8b6e7f0afa47e283053e08d9'

Et il retournerait myDarnPassword, plus toutes les collisions qui se seraient produites.

Avec suffisamment de puissance et de temps de traitement, vous pourriez créer des milliards de combinaisons et casser assez facilement un grand nombre de mots de passe en très peu de temps (je recommanderais peut-être de diviser les bases de données en longueurs de mot de passe en raison du simple nombre). Cependant, vous auriez besoin d'une quantité colossale d'espace sur le disque dur.

À ce stade, tout ce que vous avez à faire est de le rechercher sans gaspiller la puissance de traitement en forçant tout à 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 dans la base de données, il est considéré comme un mot de passe valide. Vous pouvez ensuite autoriser l'utilisateur à se connecter.

Saler le hachage peut aider à vaincre cette attaque, mais cela ne vous sauvera pas contre les collisions. Vous pouvez comparer les hachages piratés à votre liste de hachage qui a généré des collisions, puis entrer 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.

Peu importe si quelqu'un déchiffre mes mots de passe? Je m'en fous!

Vous trouverez ci-dessous une petite collection d'exemples de ce que les hameçonneurs et autres personnes malveillantes pourraient utiliser avec vos mots de passe en texte brut non hachés et non salés. Il ne peut pas nécessairement être utilisé pour vous cibler directement, mais disons que Hacker veut cibler Person A. Déduisons comment vous pouvez cibler Person A.

Vous êtes Hacker. Votre travail consiste à pirater des sites Web et à développer une base de données pour agréger ces informations.
Person A est une personne d'intérêt. Person 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 password qu'ils utilisent pour ce site Web.
Vous pouvez maintenant essayer de vous connecter à leur email address avec password que vous avez volé sur ce site Web. Doux, ça marche!
Maintenant que vous avez accès à leur e-mail, 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 Person B.
Vous pouvez réellement google les noms d'utilisateur et adresses e-mail de certaines personnes, et cela pourrait montrer 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 pouvez-vous simplement en déduire dans quoi ils sont. Maintenant vous pouvez pretend to be like them, ou recherchez des informations supplémentaires. Les informations/activités pourraient comprendre:
- Noms d'utilisateur. Person A publie en ligne en tant que 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 plus de sa personnalité sur d'autres sites?
- Mots de passe. Peut être Mark Buffalo a le même mot de passe sur ce site Web. Peut-être pouvez-vous vous connecter à ce site Web et voir ses communications privées avec les autres?
- Informations personnelles. Parce que vous connaissez l'identité de Mark Buffalo, et s'il partage personal information sur certains sites Web? Et s'il poste 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, sauf si vous n'incluez pas 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 de collecte et d'utilisation des informations contre vous. C'est, après tout, un Information Security forum, donc je veux utiliser cet exemple.
- Informations sur la famille. Maintenant, ça devient effrayant. Nous avons les informations personnelles de Mark Buffalo. Examinons son réseau social. 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 déduire cela de son e-mail 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 e-mail plus tôt, nous constatons qu'il possède é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.
- surpation 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 tireur droit et qu'il n'a jamais recherché d'escorte, ou quoi que ce soit de ce genre? Eh bien, vous pouvez maintenant le transformer en réprouvé recherchant une escorte, au moins en apparence, en utilisant ses informations d'identification pour usurper son identité en ligne. Imaginez les dommages que pourrait causer un politicien accusé à tort et forcé de démissionner.
- Des choses qui facilitent le piratage d'autres personnes. Vous pouvez ensuite envoyer des e-mails à Person B avec des pièces jointes infectées, et faites comme si vous le connaissiez. Vous avez lu suffisamment de courriels, vous pouvez donc imiter Mark Buffalo au point que tu ressembles à lui. Vous créez l'e-mail d'une manière qui laisse Person B sans méfiance sur ce qui se passe réellement, et maintenant vous pouvez faire la même chose pour Person 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. Salez et hachez vos mots de passe, utilisez des algorithmes de hachage résistants aux collisions tels que bcrypt et scrypt, et empêchez les attaques par injection SQL. Je vous en prie, ne me transformez pas en 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).

Soit dit en passant, félicitations pour votre éventuel recours collectif si vous êtes piraté.

Selenog · Answer

Un type courant 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é. L'obtention des 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 complet en lecture sur la base de données, il peut toujours accéder en écriture via les mots de passe, en pouvant se connecter au compte et modifier facilement certaines données.

user90546 · Answer

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. Pas vous, pas votre collègue, pas le DBA. Personne. Aussi simple que cela...

Thor Erik · Answer

Une partie du salage consiste à rendre l'analyse et le vol du mot de passe plus difficiles et à utiliser 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 saline 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 langues.

Nick Gammon · Answer

s'ils ont accès à la base de données, ils n'ont en fait pas 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. En effet, de nombreuses personnes réutilisent le même mot de passe. Ainsi, le mot de passe de votre club colombophile pourrait être le même qu'il utilise pour ses opérations bancaires en ligne.

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

Celles-ci sont également précieuses. J'ai perdu la trace du nombre de courriels que j'ai reçus récemment de "eBay" ou "Apple" affirmant que mon compte a été limité, sauf si je "vérifie" mes coordonnées. Ils sont généralement manifestement faux parce qu'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 envoi d'aspect réaliste, en demandant plus d'informations personnelles. Par exemple:

Cher M. Smith de 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.

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

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

SEM · Answer

Le but d'un sel est double: tout d'abord, 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", l'utilisateur A peut déduire qu'il a le même mot de passe que l'utilisateur B.

Deuxièmement, il introduit un ralentissement significatif pour toute personne ayant accès à la base de données qui souhaite forcer les mots de passe par une attaque par dictionnaire. Sans sel, l'attaquant peut simplement hacher "TRUSTNO1" pour obtenir le hachage "QUERTYU123", puis scanner la colonne de mot de passe pour voir si ce texte apparaît. Avec un sel, l'attaquant doit ressasser "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 de dictionnaire.

codykochmann · Answer

Je peux voir ce que vous voulez dire si l'attaquant a également pu accéder à la base de données. La chose est cependant, un système de sécurité bien conçu ne permettra à la base de données de stocker des informations que l'utilisateur et le serveur ont chiffrés 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 les hacher 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 compromises. De cette façon, même en cas de violation, les données de l'utilisateur sont toujours en sécurité.

anomaly · Answer

Dans ce contexte, le point de hachage est basé sur l'idée d'une fonction unidirectionnelle ou Trapdoor: 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 identiques, tant mieux; sinon, le mot de passe était incorrect et l'utilisateur ne devrait pas pouvoir accéder au système. Pour que cela fonctionne, le hachage a besoin de deux propriétés: (1) différentes valeurs originales de hachage à différentes valeurs; (2) Il est difficile 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, laissant une impression sur le bus, des actes d'un employé mécontent, etc.), tout ce qu'il obtient 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, donc ce n'est pas très utile pour un pirate. Si les mots de passe en texte brut 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 essentiellement 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 ne faites 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 se fier à l'administrateur particulier d'un site pour en trouver une décente. 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 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 juste les mots de passe les plus couramment utilisés), alors il est trivial d'inverser le hachage; il suffit de le chercher dans le tableau.

Karl Bielefeldt · Answer

En plus des autres réponses, gardez à l'esprit qu'il existe de nombreux degrés de vulnérabilité entre un accès totalement sécurisé et complet à une base de données. Une vulnérabilité peut exposer uniquement certains mots de passe, ou uniquement les premiers caractères de celui-ci, ou être difficile à associer à un utilisateur particulier, etc. Le hachage et le salage peuvent empêcher une brèche mineure de se transformer en une brèche majeure.

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.

RVD · Answer

Le chiffrement des informations utilisateur comme le nom, l'e-mail, etc. et le stockage dans la base de données plutôt que de les stocker dans un 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 provenant de n'importe quel client a son secret. Comme il s'agit de leurs données et qu'il est de la responsabilité des développeurs de les stocker d'une manière qui rend difficile pour le hack de donner un sens à des informations de bas niveau ou à des informations top secrètes. En outre, le décryptage et le cryptage des données doivent être effectués côté serveur, car les serveurs sont généralement conservés derrière le pare-feu. Il devient donc plus sûr du point de vue de la sécurité.