Question:
Pourquoi seuls les mots de passe sont-ils hachés?
Aman Kothari
2016-10-29 02:26:48 UTC
view on stackexchange narkive permalink

Je viens d'apprendre quelques choses sur les algorithmes de hachage - MD5 et SHA-1. Donc, si je ne me trompe pas, les mots de passe sont hachés afin que dans une situation rare où votre base de données soit compromise, un pirate informatique ne puisse pas voir tous les mots de passe de votre base de données car les mots de passe sont hachés. MD5 n'est plus sûr car la plupart des mots de passe courants et leurs valeurs hachées sont disponibles sur Internet. Et par conséquent, les gens utilisent maintenant d'autres algorithmes de hachage.

Mes questions sont donc:

  1. Le piratage d'une base de données est-il aussi simple? Je veux dire au lieu de trouver de nouvelles façons de hacher, pourquoi ne peuvent-ils pas rendre leur base de données plus sécurisée ou "à l'épreuve du piratage"?

  2. Si un pirate parvient à pirater une base de données , pourquoi voudrait-il connaître les mots de passe hachés? Je veux dire qu'il peut changer d'autres colonnes de données. Par exemple, il pourrait rechercher son nom d'utilisateur et augmenter son solde bancaire. Alors, tous les champs ne devraient-ils pas être hachés?

Vous avez un malentendu sur ce que MD5 est dangereux.Voir [ici] (http://security.stackexchange.com/q/19906/46979).C'est une question de vitesse, pas de résultats publiés.(Ce dernier peut être surmonté avec un sel long et aléatoire.) SHA-1 souffre du même problème.
Souvent, les pirates ne parviennent pas à «pirater la base de données», c'est-à-dire que les pirates ne parviennent pas à accéder à la base de données.Au lieu de cela, ils parviennent simplement à vider la base de données.Ils ne peuvent donc pas le changer mais peuvent obtenir les mots de passe hachés.Alors ils "pourquoi voudrait-il le hasch" c'est parce que c'est ce qu'il obtient.À partir de là, il voudrait essayer d'inverser le hachage en utilisant des tables arc-en-ciel, etc. pour obtenir au moins quelques mots de passe qui correspondent à certains des hachages.Ensuite, il peut se connecter.Notez qu'il ne pourrait presque JAMAIS obtenir tous les mots de passe.Seulement quelques.Mais alors il pourrait se connecter.
Copie possible de [Comment hacher les mots de passe en toute sécurité?] (Http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords)
Je souhaite vraiment que ma banque hache mon solde.Je trouverais une collision numérique stupidement élevée pour le hachage et j'achèterais le monde.
@ceejayoz, vous êtes beaucoup plus susceptible de gagner à la loterie que de trouver une collision numérique de votre solde, si le hachage n'a pas de faiblesse connue de résistance aux collisions.
@tsukumogami Oui, mais OP mentionne MD5 et SHA1.Donc, je suis un multi-quintillionnaire en herbe!
Cette question m'a fait réfléchir: en fait, les noms d'utilisateurs sont également une sorte de "précieuses informations" (les utilisateurs sont susceptibles d'utiliser le même nom d'utilisateur sur différents services, il est donc plus facile de faire correspondre un mot de passe piraté avec un autre service en connaissant le nom d'utilisateur).Dans la mesure où, c'est une chose valable à se demander, et le hachage des noms d'utilisateur pourrait en effet valoir la peine.Seulement ... comment éviter les collsions?Les noms d'utilisateur doivent être uniques et, bien que peu probables, des collisions de hachage sur différents noms d'utilisateur _ sont_ possibles ...
@Damon: Voir [Pourquoi les gens ne hachent pas et ne salent pas les noms d'utilisateur avant de les stocker] (http://security.stackexchange.com/q/25374/8715)
"Le piratage de la base de données est-il aussi simple que cela?".Non. Le piratage se produit dans les nombreuses couches de personnes et de systèmes entre le pirate et la base de données.Votre porte de chambre forte est inutile si le garde donne la clé à quelqu'un.
@tsukumogami: Oui, mais avec du matériel informatique facilement disponible, je peux calculer un million de hachages par seconde.Je ne peux pas acheter de billets Powerball aussi vite car je suis limité par le prix d'achat de 2 $.
Je voudrais aborder l'idée fausse sous-jacente ici: le hachage n'est pas pour vous protéger.Votre base de données est compromise, et probablement d'autres systèmes avec.Trop tard pour toi.Le hachage des mots de passe est fait pour protéger vos UTILISATEURS, car ils utilisent probablement les mêmes mots de passe sur plusieurs sites.
Si vous hachez le solde bancaire de l'utilisateur, comment l'ordinateur connaîtrait-il son solde bancaire?L'utilisateur doit-il saisir son solde bancaire et le faire vérifier par l'ordinateur?
@dan04 Si votre hachage n'a pas de faiblesse connue, peu importe si vous pouvez calculer un million ou un milliard de hachages par seconde, la chance de trouver une collision est toujours bien inférieure à la chance de gagner la balle de puissance, enplusieurs ordres de grandeur.
@tsukumogami La question est de savoir si c'est * assez * des ordres de grandeur pour qu'il y ait encore moins de chance d'obtenir une collision sur 2 $ de temps serveur par rapport à gagner le powerball sur un ticket.
@Random832 Oui, c'est plus que suffisant, à moins que nous ayons de nouvelles découvertes fondamentales en mathématiques et / ou en physique.Mais je pense que nous avons suffisamment avancé.Si vous voulez un calcul de détails, nous pouvons peut-être prendre cette conversation pour discuter?
Pensez à quelqu'un qui vole le type de sauvegarde de la base de données et au fait que beaucoup de vos utilisateurs auront le même mot de passe sur votre système que sur leur banque ……
Pour la même raison, il est souvent préférable de payer une autre entreprise pour stocker les détails de crédit de vos clients, de sorte que vous ne stockez que le «jeton», donc vous n'êtes pas responsable si les détails de la carte sortent.
Onze réponses:
deviantfan
2016-10-29 03:44:30 UTC
view on stackexchange narkive permalink

Quelques choses en premier:

  • Oubliez immédiatement MD5. C'est vieux et faible.
  • Idéalement, oubliez également SHA1. Il existe SHA2 et SHA3.
  • Ces algorithmes de hachage dans leur forme pure sont utiles pour beaucoup de choses, mais pas pour les mots de passe. Utilisez-les en combinaison avec par exemple. PBKDF2, ou utilisez bcrypt (et n'oubliez pas le salage).

Donc, si je ne me trompe pas, les mots de passe sont hachés afin que dans une situation rare où votre base de données soit compromise, un pirate ne puisse pas voir tous les mots de passe de votre base de données car les mots de passe sont haché.

Correct. Bien que cela n'aidera pas à rendre votre serveur plus sécurisé (après tout, il est déjà compromis dans une telle situation), cela empêche par exemple. l'attaquant utilisant les mots de passe sur d'autres sites. Malheureusement, la plupart des gens utilisent un mot de passe pour plusieurs choses.

Le piratage d'une base de données est-il aussi simple que cela? Je veux dire au lieu de trouver de nouvelles façons de hacher, pourquoi ne peuvent-ils pas rendre leur base de données plus sécurisée ou "à l'épreuve du piratage"?

Vous pourriez (et vous devriez). Mais:

  • Même avec tous vos efforts, il y a toujours une chance que l'attaquant puisse y accéder. Bogues dans les logiciels et les appareils que vous ne connaissez pas et / ou que vous ne pouvez pas corriger, et bien d'autres choses.
  • Souvent, vous ne pouvez pas donner le meilleur de vous-même à cause des gestionnaires qui ne pensent pas que la sécurité est important, n'avez pas de budget pour cela, etc.

Si un pirate parvient à pirater une base de données, pourquoi voudrait-il connaître les mots de passe hachés? Je veux dire qu'il peut changer d'autres colonnes de données. Par exemple, il pourrait rechercher son nom d'utilisateur et augmenter son solde bancaire. Alors, est-ce que tous les champs ne devraient pas être hachés?

Si tous les champs sont hachés, la base de données est inutile pour vous aussi; donc vous ne pouvez pas faire ça. N'oubliez pas qu'un bon hachage ne peut pas être inversé.

Comme indiqué ci-dessus, dès que votre base de données / serveur est compromise, les dommages pour vous sont déjà survenus. Les mots de passe hachés empêchent simplement l'attaquant d'accéder à d'autres comptes de vos utilisateurs (et certains utilisateurs vous poursuivraient donc, le hachage vous aide également).

Je suis d'accord avec la plupart de votre réponse, à l'exception de la recommandation de bcrypt: il y a scrypt et argon2, pourquoi devons-nous toujours recommander un algo obsolète?En outre, vous pourriez probablement utiliser le mot à la mode «sécurité en profondeur» pour répondre aux raisons du hachage.
@axapaxa Attends, quoi?argon2 n'a que 1 an et il y a déjà deux attaques publiées, et scrypt est [manifestement plus faible] (http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html) quebcrypt pour les applications les plus courantes.Il n'y a absolument rien de mal à recommander bcrypt, même en 2016.
La cryptographie @axapaxa (c'est-à-dire les mathématiques) ne devient pas obsolète simplement parce qu'elle est ancienne.En fait, il devient plus fort à mesure que de plus en plus de gens l'examinent et ne trouvent pas de défauts.[Blowfish] (https://en.wikipedia.org/wiki/Blowfish_ (cipher)), tel qu'utilisé par bcrypt, reste sécurisé.[bcrypt] (https://en.wikipedia.org/wiki/Bcrypt) est en outre conçu pour éviter l'obsolescence en vous permettant d'augmenter le coût de la fonction de hachage.Les utilisateurs de bcrypt peuvent se défendre contre les attaques par force brute de plus en plus puissantes ou les futures failles potentielles de Blowfish en augmentant le facteur de mise à l'échelle.
Pour ajouter au «pourquoi» du hachage: même dans un scénario de sécurité parfait, vous voulez toujours hacher, car ** personne à part l'utilisateur lui-même ** ne doit connaître ce mot de passe.Les administrateurs de base de données et autres yeux légitimes sur la base de données ne devraient ** jamais ** voir le mot de passe de l'utilisateur.
@axapaxa en crypto, si un algorithme est plus récent, alors c'est un * inconvénient * et si toutes les autres choses sont égales, alors l'algorithme plus ancien doit être préféré.Si la force est comparable et qu'il n'y a pas de vulnérabilités actuellement connues, alors l'algorithme "obsolète" est plus fiable et le nouvel algorithme est plus susceptible d'avoir de nouvelles vulnérabilités découvertes car il n'a pas été examiné autant.
Personne de sensé n'utiliserait MD5 ou SHA1 pour le hachage de mot de passe dans un nouveau système.Mais les faiblesses de MD5 et SHA1 ne sont pas encore assez graves pour constituer une menace pour le hachage de mot de passe.Lorsque les mots de passe sécurisés via l'un de ces hachages ont été brisés, cela a toujours été dû au fait que le hachage était appliqué de manière incorrecte plutôt qu'à des faiblesses dans le hachage lui-même.En d'autres termes, si ces systèmes avaient utilisé SHA2 ou SHA3 de la même manière non sécurisée qu'ils utilisaient MD5 ou SHA1, la vulnérabilité aurait été tout aussi mauvaise.
@kasperd "Mais les faiblesses de MD5 et SHA1 ne sont pas encore assez graves pour constituer une menace pour le hachage de mot de passe."- ce n'est pas vrai.MD5 peut être haché sur un seul GPU à prix modique à un taux d'environ 10 ^ 9 hachages par seconde.Cela signifie que tout mot de passe de dictionnaire peut être piraté presque instantanément et de simples modifications des mots du dictionnaire en quelques secondes seulement.Même une phrase secrète de 4 mots hachée par MD5 peut être devinée en quelques mois.Je ne peux pas trouver de chiffres précis pour le hachage SHA-1 sur le matériel actuel, mais en 2012, il était environ 1/3 aussi rapide que MD5, donc pas beaucoup mieux.
@PeriataBreatta ** La vitesse n'est pas une faiblesse dans une fonction de hachage cryptographique. ** MD4, MD5, SHA0, SHA1, SHA2, SHA3, etc. sont tous conçus pour être aussi rapides que possible.Ce n'est pas une faiblesse que ceux-ci soient rapides à calculer.Si vous basez votre sécurité sur l'hypothèse qu'un attaquant doit passer des millisecondes à l'ordinateur pour la fonction de compression (ou éponge) de l'un d'entre eux, vous avez une conception défectueuse.Vous devez vous assurer que l'attaquant doit évaluer le hachage beaucoup plus de fois pour attaquer votre système, sinon votre système n'est pas sécurisé.
@PeriataBreatta Ces cas où les hachages MD5 ont été forcés brutalement n'étaient ** pas ** dus à l'utilisation de MD5.Et les faiblesses connues de MD5 n'ont joué aucun rôle dans ces attaques.Les faiblesses de ces mots de passe n'étaient pas causées par MD5 mais plutôt par deux autres problèmes: ** 1. ** Les hachages n'utilisaient aucun sel.** 2. ** Les mots de passe étaient si faibles qu'aucun hachage de mot de passe ne pouvait les protéger.
J'ajouterais au commentaire d'@kasperd's sur la vitesse, qu'un algorithme plus lent peut également aider à compromettre votre système en le rendant plus vulnérable aux attaques DoS.Plus vous absorbez de ressources lors du hachage d'une entrée, plus il est facile de lier toutes les ressources disponibles.
@kasperd Je crois comprendre que les mots de passe divulgués par l'attaque Ashley Madison, par exemple, provenaient de la fissuration d'une base de données MD5 salée.Comme plus de 11 millions d'entre eux ont été piratés, beaucoup d'entre eux étant de 10 caractères ou plus et / ou contenant des symboles ou des chiffres, ils ne peuvent certainement pas avoir * tous * des mots de passe faibles.
@kasperd - Je suis d'accord que la vitesse n'est pas une faiblesse dans une fonction de hachage.C'est, cependant, une faiblesse dans un mécanisme de vérification de mot de passe, c'est pourquoi une fonction de hachage simple * ne doit pas être utilisée à cette fin *, et pourquoi nous avons des algorithmes spécifiquement conçus pour le travail, comme bcrypt ou PBKDF.
@all, bcrypt est obsolète, non seulement parce qu'il est vieux (c'est pourquoi nous n'utilisons pas 3DES même si nous savons qu'il est sécurisé - et il a reçu de loin la plupart des crypto-analyses), mais parce que l'auteur de blowfish a déclaré qu'il était obsolète.corsiKa: argon2 a publié deux attaques, qui n'ont pas vraiment montré grand-chose, et les deux étaient contre un point d'une variante (dire qu'il est cassé est aussi étiré que d'appeler AES cassé).et l'article que vous avez signalé prétend que scrypt est aussi sécurisé que bcrypt, ou plus.Et le point le plus bas de cet article était que bcrypt> scrypt pour l'instant (2014) ... Je suis donc toujours d'accord.
@kasperd - D'autres hacks récents impliquant du MD5 salé incluent les forums DOTA2, à partir desquels environ 1,6 mots de passe sur un total de 2 millions ont apparemment été récupérés.Et pourtant, lorsque 43 millions de mots de passe weebly.com (bcrypt) ont été publiés il y a quelques semaines, * presque aucun * n'a été piraté.Voulez-vous toujours soutenir que le MD5 salé est assez bon?
@PeriataBreatta Brute forcer 11 millions de hachages de mots de passe salés de mots de passe de 10 caractères n'est pas une tâche facile pour n'importe quel hachage, pas même MD5.Si nous supposons 6 bits d'entropie par caractère, cela équivaudra à forcer brutalement 83,5 bits.C'est à peu près le travail effectué par tout le matériel spécialisé utilisé pour l'extraction de bitcoins sur une période de deux mois.Non pas que vous puissiez utiliser le même matériel, car vous devrez concevoir du matériel spécifiquement destiné au hachage de mot de passe.Je ne pense pas que quiconque investirait autant dans la destruction d'une base de données de mots de passe.
@axapaxa Les algorithmes cryptographiques ne sont jamais abandonnés en raison de l'âge.Ils ne sont abandonnés que lorsque des preuves de faiblesses sont trouvées.Plus un algorithme vieillit sans qu'aucune faiblesse ne soit trouvée, plus il y a de raisons de continuer à l'utiliser - jusqu'à ce que le matériel devienne suffisamment efficace pour le forcer brutalement.Les raisons d'arrêter d'utiliser 3DES sont qu'il n'est pas particulièrement rapide et que la taille de bloc n'est que de 64 bits, ce qui est beaucoup trop petit pour la plupart des cas d'utilisation modernes.Un algorithme trop récent ne devrait être utilisé qu'avec beaucoup de prudence.
@PeriataBreatta Je n'ai pas utilisé les mots assez bien sur MD5.Ce que j'ai dit, c'est qu'aucune des faiblesses de MD5 ne vous aidera, même la moindre des choses, à casser les hachages de mots de passe.Des fuites de hachages MD5 non salés se sont produites, et seuls les mots de passe les plus forts peuvent y survivre.Mais tant que vous utilisez un mot de passe fort, il survivra à une fuite d'un hachage MD5 non salé.Si les hachages sont salés, les mots de passe peuvent être quelques bits plus faibles et survivre.Je trouve ironique que vous considériez un mot de passe avec moins de 70 bits d'entropie comme fort et que vous considérez un hachage de 128 bits comme faible.
"Bien que cela n'aidera pas à rendre votre serveur plus sécurisé" - cela pourrait car la base de données peut être compromise séparément - par exemple par injection SQL ou simplement un système esclave de réplication a été compromis en lecture seule - du reste du système.Mais un stockage approprié des mots de passe vous permet de vous donner le temps de tout verrouiller et de notifier aux utilisateurs de changer le mot de passe immédiatement plutôt que de le faire évoluer vers un compromis complet du système.
Xander
2016-10-29 03:48:36 UTC
view on stackexchange narkive permalink

MD5 et SHA-1 ne sont plus sûrs non plus parce que "la plupart des hachages de mots de passe sont désormais sur Internet". L'utilisation de sels pour rendre les hachages de mots de passe uniques au monde rend en fait cela impossible. Ils sont obsolètes parce qu'ils sont trop rapides, et trop de mots de passe candidats peuvent être testés contre un hachage volé trop rapidement pour plus de confort.

L'inconvénient du hachage est qu'il n'est pas réversible. C'est pourquoi il ne peut pas être utilisé pour toutes les données sensibles. Votre solde bancaire, par exemple, n'est pas très bon pour vous ou pour la banque s'il s'agit de hachages, et aucun de vous ne sait ce que c'est.

Juste pour donner quelques chiffres: en 2009, un GPU haut de gamme pouvait calculer environ 200 millions de hachages MD5 par seconde.Aujourd'hui, vous pouvez obtenir un GPU 6 fois plus rapide que ce GPU pour moins de 100 £, ce qui vous permet de gagner bien plus de 10 ^ 9 hachages par seconde.Les chiffres pour SHA-1 seront probablement un peu plus bas, peut-être 1/3 ou 1/4 autant.Si vous avez de l'argent à dépenser sur le projet, vous pouvez obtenir une [machine unique qui peut hacher plus de 6x10 ^ 10 hachages SHA-1 par seconde] (http://www.zdnet.com/article/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second /), et c'était il y a 4 ans.
Que diriez-vous d'une fonction inversible très lente pour d'autres données?Dites, le déchiffrement prend de l'ordre 1s.Bien pour une seule recherche de mes détails, mais douloureux pour tout parcourir.Est-ce jamais utile?
@innisfree Je dirais que vous pensez dans le bon sens, du moins pour certains systèmes.Généralement, les systèmes appartiennent à l'un des deux modèles.Dans le premier modèle, quelqu'un (propriétaires, administrateurs, etc.) a besoin d'accéder à des données agrégées, auquel cas ce type de fonction serait d'un coût prohibitif.
@innisfree Dans le 2ème modèle, où seuls les propriétaires de données ont besoin d'accéder à leurs données, ou les données ne sont jamais agrégées entre plusieurs utilisateurs, cela pourrait effectivement fonctionner, mais nous avons un mécanisme alternatif que nous utilisons déjà et qui est encore meilleur .... Un PBKDF (comme PBKDF2, bcrypt, scrypt, etc.) est utilisé pour dériver une clé, et ce processus est l'endroit où le facteur de travail que vous suggérez entre en jeu.
@innisfree La clé est ensuite utilisée (généralement indirectement) pour décrypter les données.Cela présente l'avantage supplémentaire que non seulement la recherche de la clé correcte est lente, mais la clé correcte n'est correcte que pour les données d'un utilisateur.Cela rend non seulement le forçage brutal des données pour plusieurs utilisateurs lent, mais impossible.
SHA-1 est en fait probablement pire que MD5, étant donné la prolifération des machines d'extraction Bitcoin qui ont du silicium dédié pour effectuer des hachages SHA1.À ce stade, vous pouvez obtenir des cartes Bitcoin pouvant effectuer 14 millions de MHash / seconde.Cela représente 1,4 * 10 ^ 12 hachages SHA-1 par seconde et cela ne coûte pas plus de 2500 USD.C'est beaucoup de puissance de hachage.L'ensemble du réseau Bitcoin effectue environ 10 ^ 18 hachages SHA-1 par seconde, 24/7
Gabor Lengyel
2016-10-29 03:42:38 UTC
view on stackexchange narkive permalink

  1. Bien que ce ne soit probablement pas aussi simple avec des systèmes bien configurés à l'esprit, de multiples vulnérabilités au niveau du système d'exploitation ou de l'application (comme l'injection SQL, peut-être même une inclusion de fichier) peuvent conduire à une compromission de la base de données assez souvent le cas en réalité. Protéger les mots de passe en les hachant est un exemple de défense en profondeur. Même si une ligne de défense échoue, il devrait être relativement difficile d'accéder aux mots de passe réels.

  2. Les mots de passe sont une bonne cible pour plusieurs raisons. D'une part, ils permettent l'usurpation d'identité des utilisateurs, plutôt que la lecture, la modification ou la suppression de données avec le compte de l'attaquant (éventuellement compromis). Les utilisateurs ont également tendance à réutiliser les mots de passe, de sorte qu'un mot de passe volé dans une application a de très bonnes chances d'être valide pour d'autres comptes du même utilisateur. Quant à savoir pourquoi les autres données ne sont pas hachées - le hachage est un moyen, vous ne pouvez pas récupérer la valeur d'origine d'un hachage (du moins pas de manière triviale, en réalité et avec de nombreuses fonctions de hachage, vous avez de bonnes chances, mais ignorons cela pour un moment). Être à sens unique signifie que les fonctions de hachage sont bonnes pour vérifier si un mot de passe entré est le même que celui stocké, mais ce n'est pas bon pour stocker les données dont vous avez réellement besoin sous leur forme non chiffrée. Et c'est la solution que vous cherchiez peut-être, le cryptage, par opposition au hachage. C'est en effet une bonne idée de crypter des données sensibles dans une base de données, mais cela a aussi ses propres problèmes, par exemple la gestion des clés.

Le nom d’utilisateur, par exemple, n’est pas haché car c’est probablement ainsi que l’application trouve le hachage du mot de passe _qu’il a besoin de comparer - elle interroge «renvoie le hachage à partir de la ligne où user = _entered-user-name_» et hache le mot de passe saisi etcompare ce hachage avec le hachage retourné.
@DoktorJ Sans oublier que les noms d'utilisateur utilisés pour les connexions doivent être uniques.Les hachages n'ont pas de garantie d'unicité.Cela peut sembler évident, mais de nombreux candidats à l'entretien m'ont convaincu du contraire - apparemment, un hachage de quatre octets d'une séquence aléatoire de cent octets sera toujours unique: / Je me demande pourquoi nous n'utilisons pas ces fonctions de hachage comme algorithmes de compression à la place: D
paj28
2016-10-29 03:59:31 UTC
view on stackexchange narkive permalink

Le piratage d'une base de données est-il aussi simple que cela? Je veux dire au lieu de trouver de nouvelles façons de hacher, pourquoi ne peuvent-ils pas rendre leur base de données plus sécurisée ou "à l'épreuve du piratage"?

Souvent, une base de données peut être piratée via une application Web utilisant SQL injection. Nous devons absolument fixer l'injection SQL en priorité. Cependant, dans une application volumineuse, il suffit à un développeur de faire une erreur sur une seule ligne pour introduire une telle vulnérabilité. Donc, pendant que nous essayons de l'arrêter, nous prévoyons également d'autres défenses au cas où une vulnérabilité passerait.

Si un pirate parvient à pirater une base de données, pourquoi voudrait-il connaître les mots de passe hachés? Je veux dire qu'il peut changer d'autres colonnes de données. Par exemple, il pourrait rechercher son nom d'utilisateur et augmenter son solde bancaire. Donc, tous les champs ne devraient-ils pas être hachés?

Dans de nombreux cas, l'injection SQL permet aux attaquants de lire les données, mais pas de les modifier. Si les mots de passe n'étaient pas hachés, ils pouvaient se connecter en tant qu'autres utilisateurs et apporter des modifications. Le hachage du mot de passe permet d'éviter cela. De plus, les utilisateurs réutilisent souvent les mots de passe sur de nombreux sites Web, même si ce n'est pas une bonne pratique de le faire.

Pourquoi seuls les mots de passe sont-ils hachés?

Dans une application bien conçue, tous les jetons d'authentification sont hachés. Cela inclut les identifiants de session et les jetons de réinitialisation des mots de passe, ainsi que les mots de passe. Les autres données (par exemple, votre solde bancaire) ne sont pas hachées, car l'application a besoin des données au format brut pour fonctionner.

La défense en profondeur est en effet un concept clé.En outre, vous pouvez mentionner que le hachage empêche les utilisateurs légitimes (tels que DBA) de connaître le mot de passe.
@spectras - J'ai tendance à éviter cette affirmation.Les hachages arrêtent les administrateurs de base de données dans certaines circonstances, mais un administrateur système malveillant pourrait modifier le système pour enregistrer les mots de passe en texte brut.
H. Idden
2016-10-29 15:35:52 UTC
view on stackexchange narkive permalink

Le piratage d'une base de données est-il aussi simple que cela? Je veux dire au lieu de trouver de nouvelles méthodes de hachage, pourquoi ne peuvent-ils pas rendre leur base de données plus sécurisée ou "à l'épreuve du piratage"?

Pourquoi avons-nous besoin d'hôpitaux? Pourquoi ne pouvons-nous pas rendre la route plus sûre au lieu d'avoir des hôpitaux?

Un système totalement "anti-piratage" est une illusion. Il existe des millions de façons de pirater un système. Vous devez vous défendre contre tous. Un attaquant n'a besoin d'en trouver qu'un.

Cela vous oblige à connaître toutes les méthodes. Et que vous n'avez pas fait d'erreur (regardez simplement le paramètre par défaut pour Mongo-DB: accès administrateur non authentifié, puis combinez-le avec de nombreux administrateurs définissant la base de données pour être accessible depuis Internet pour plus de commodité ou en raison de manuels médiocres) . Et ayez les ressources. Et pour rester à jour lorsque de nouvelles failles sont découvertes. Et il en va de même pour tous les fournisseurs de logiciels, de services et de matériel que vous utilisez. Et qu'aucun d'eux n'avait de mauvaises intentions. Et qu'il existe des mises à jour pour les nouvelles failles découvertes (les smartphones Android sont connus pour ne pas être très bien entretenus avec les mises à jour de sécurité). Et qu'il n'y a pas de défauts inconnus que l'attaquant connaisse.

Etes-vous sûr que vous vous êtes défendu contre tous? A qui faites-vous confiance? Que diriez-vous de l'administrateur qui a été abandonné et qui a toujours accès à une copie de la sauvegarde de la base de données? Avez-vous correctement effacé le stockage avant de le revendre ou de le jeter? Qui a accès aux sauvegardes?

Si un pirate parvient à pirater une base de données, pourquoi voudrait-il connaître les mots de passe hachés? Je veux dire qu'il peut changer d'autres colonnes de données. Par exemple, il pourrait rechercher son nom d'utilisateur et augmenter son solde bancaire.

  1. Il se peut qu'il n'ait qu'un accès en lecture seule à la base de données. Par exemple, lorsqu'il a eu une sauvegarde entre ses mains alors qu'elle était stockée sur un serveur Web non sécurisé ou que son vecteur d'attaque ne permet que la lecture.
  2. Il se peut qu'il n'ait accès qu'à une partie du système où les mots de passe sont stockés, mais pas au système où les soldes sont stockés.
  3. De nombreuses bases de données professionnelles disposent d'une piste d'audit. Disons que vous modifiez votre solde dans la base de données. Cela pourrait désactiver leurs alarmes parce que le système ne voit aucune réduction correspondante dans un autre solde et aucune autorisation pour cette transaction, etc. et il est facilement visible. Si vous vous connectez en tant qu'autre utilisateur et que vous appuyez sur transférer 1000 $ vers un autre compte, cela semblera plus légitime.
  4. Vous pouvez utiliser les données de connexion pour usurper l'identité d'un autre utilisateur et il sera blâmé (de nombreux fournisseurs plus importants déjà avoir une heuristique pour détecter de telles choses automatiquement ou lorsqu'elles sont réclamées)
  5. Heure de l'attaque (-vector) et heure d'accès: vous n'avez besoin d'attaquer qu'une seule fois, mais vous pouvez utiliser les informations d'identification plus tard (de nombreux utilisateurs ne changent pas de mot de passe pendant des années ou jamais)
  6. De nombreux utilisateurs moins techniques réutilisent les mots de passe sur d'autres sites
  7. Vous avez plus de temps avant que l'attaquant puisse se faire passer pour les utilisateurs après avoir attaqué
    8. ol>

    Ce sont les premières raisons auxquelles j'ai pensé et il y en a bien d'autres.

Nick Gammon
2016-10-31 09:56:03 UTC
view on stackexchange narkive permalink

Tous les champs ne devraient-ils pas être hachés?

C'est une question intéressante, alors considérons les ramifications si (disons) le nom d'utilisateur a également été haché. En ce moment, je suis "Nick Gammon" sur Stack Exchange. Si mon nom d'utilisateur était haché, au lieu d'un message de Nick Gammon , nous verrions un message de 80a8694f4a2950e075d142e97ddb809b415bf85f084dafd9fb78fed9551905f3 en réponse à une question de sup> 1 . Vous pouvez voir que ce serait incroyablement fastidieux. (N'oubliez pas que vous ne pouvez pas inverser un hachage pour récupérer l'original).

OK, vous pourriez dire "eh bien, gardez un nom de connexion (que vous hachez) et aussi un nom d'affichage". Mais si vous avez vu que mon nom d'affichage était "Nick Gammon", vous pourriez deviner que c'était aussi mon nom de connexion (ou une variante simple de celui-ci), donc le hachage n'a rien donné.

Alors vous pourriez craignez que si quelqu'un accède à la base de données, il puisse également voir les adresses e-mail, alors vous les hachez également. Mais vous ne pouvez pas envoyer un e-mail à une adresse e-mail hachée (par exemple pour vous informer de nouveaux messages ou d'une baisse de votre solde bancaire), cela ne fonctionnera pas. OK, donc vous conservez l'adresse e-mail sous forme de texte brut, mais maintenant vous pouvez probablement déduire le nom d'utilisateur de l'adresse e-mail.

pourquoi ne peuvent-ils pas rendre leur base de données plus sécurisée ou "anti-piratage"?

Aucune conception ne permettra à un employé de confiance d'être corrompu pour faire une copie de la base de données. Si les données sont là, les personnes disposant d'une autorisation suffisante devront être en mesure d'y accéder, ou elles peuvent tout aussi bien ne pas exister.

Je pense que certaines des fuites de sécurité récentes sont survenues dans des organisations qui pensaient leur base de données était si "à l'épreuve du piratage" qu'ils n'avaient pas besoin de se soucier de hacher leurs mots de passe. Oups.

  1. Des marques supplémentaires pour savoir qui c'est. :)
_Des notes supplémentaires pour savoir qui c'est_ C'est une question piège car le hachage que vous avez fourni n'est pas pour "Nick Gammon", mais pour "Nick Gammon \ n" ... Après avoir réalisé cela, il était alors facile de savoir quice hachage appartient à :) - il n'a fallu que 2 suppositions.Une autre bonne chose à propos des hachages est que cela me permet de montrer que je sais de qui il s'agit sans révéler la réponse en vous donnant un hachage de son nom inversé (pas de nouvelle ligne): c4354c3d27541e605c2cab2a661ef17fb7fb3d404d61f71a903f9a119a1bf0a4
Ah, je vois le problème.J'ai fait «écho à Nick Gammon» |sha256sum` où j'aurais dû ajouter l'option `-n`.Vous avez en effet raison comme vous l'avez confirmé.:)
La personne suivante qui souhaite confirmer peut faire une version entièrement en majuscules ou une version entièrement en minuscules du nom.Cependant en disant que je divulgue certaines informations.;)
djechlin
2016-10-29 18:01:59 UTC
view on stackexchange narkive permalink

La «défense en profondeur» est le principe selon lequel de multiples couches de sécurité redondantes sont les meilleures, et plus précisément qu'aucun composant d'un système sécurisé ne doit faire confiance à un autre composant d'un système sécurisé. Dans ce cas, la couche de hachage ne doit pas supposer que la base de données elle-même est sécurisée.

Vous avez posé d'autres questions techniques sur le hachage qui sont couvertes en détail dans les autres réponses, mais le principe plus fondamental de la défense en profondeur - "pourquoi verrouiller votre porte deux fois?" - est quelque chose que vous semblez manquer.

Je suis sûr que vous avez entendu suffisamment de cas de faille de sécurité très médiatisés en 2016 pour savoir que, globalement, nous en faisons beaucoup trop peu , pas trop.

AnoE
2016-10-30 04:05:40 UTC
view on stackexchange narkive permalink

Ne vous limitez pas en analysant uniquement l'attaque de l'extérieur. Vous devez voir la situation dans son ensemble ... pensez aux mesures de sécurité comme à des couches d'oignon. Vous en empilez autant que vous le pouvez dans l'espoir de fermer n'importe quel angle d'attaque. Les hachages de mots de passe sont l'une de ces couches.

Le piratage d'une base de données est-il aussi simple? Je veux dire au lieu de trouver de nouvelles façons de hacher, pourquoi ne peuvent-ils pas rendre leur base de données plus sécurisée ou "à l'épreuve du piratage"?

Peu importe à quel point il est difficile de pirater le base de données. Considérez que le hachage de mot de passe est censé protéger le mot de passe même de l'administrateur système ou de la base de données.

Notez que même si vous essayez de le faire, il n'est pas forcément facile de protéger la base de données de mots de passe. Comment la protégeriez-vous? Avec un autre mot de passe? Où stockeriez-vous ce mot de passe principal? Comment protégeriez-vous le mot de passe principal contre que quelqu'un puisse tout lire sur le système?

Si un pirate parvient à pirater une base de données, pourquoi voudrait-il connaître les mots de passe hachés?

Eh bien, pour essayer de les attaquer.

Notez comment les mots de passe sont utilisés: l'utilisateur légitime remet un nom d'utilisateur et un mot de passe en texte clair à votre écran de connexion, le texte en clair est puis haché et comparé au hachage du mot de passe.

Chaque attaquant peut faire exactement la même chose, sauf que le faire sur l'écran / l'invite de connexion est inefficace - cela prend du temps et est facilement détecté; de nombreux systèmes verrouillent un compte après quelques mauvaises tentatives.

Ainsi, lorsque l'attaquant obtient la liste des hachages de mots de passe, il peut faire le même hachage dans son propre programme - d'une rapidité aveuglante, et surtout avec "dicitonary" ou des attaques "arc-en-ciel", qui échangent RAM / stockage contre le temps.

Donc, tous les champs ne devraient-ils pas être hachés?

Vous ne pouvez pas tout hacher car votre application a besoin de connaître la valeur des autres champs, simplement. Il est difficile de récupérer la valeur d'une version hachée, même pour un utilisateur légitime.

Mais en fait, il y a il y a des bases de données qui font quelque chose comme ça - elles chiffrent (pas hachage) aussi les données réelles. Vous voulez évaluer si cela en vaut la peine du point de vue des performances, et vous devez ensuite vous assurer que le cryptage offre réellement une sécurité réelle. Par exemple, vous devez vous assurer que votre clé reste protégée pendant que la base de données doit y avoir accès, et ainsi de suite.

Le chiffrement n'est pas approprié pour les mots de passe car nous ne voulons en fait pas que les mots de passe puissent être déchiffrés (mêmes idées qu'au début => à l'intérieur des jobs, et la difficulté à rendre la clé de chiffrement plus sécurisée que les mots de passe que vous vouliez sécuriser en premier lieu).

Michael Green
2016-10-31 07:29:23 UTC
view on stackexchange narkive permalink

Parce que ce n'est pas seulement un accès distant et non autorisé qui doit être protégé. Parfois, des entiers centres de données disparaissent. Une fois que les méchants ont les disques qui contiennent les fichiers de la base de données, ils peuvent être lus à loisir. Ensuite, toutes les données non chiffrées peuvent être récupérées - numéros de carte de crédit, noms, adresse, e-mail, numéros de téléphone, historique des achats. Tout ce qui facilite le vol d'argent ou le vol d'identité.

Les bonnes pratiques actuelles consistent à crypter tout ce qui est personnellement identifiable ou financièrement sensible. Plusieurs SGBD prennent en charge le chiffrement au repos (c'est-à-dire sur le disque) et en vol (tout en étant transféré du serveur de base de données à l'application).

Arjun sharma
2016-10-29 08:08:59 UTC
view on stackexchange narkive permalink

Le piratage d'une base de données est-il aussi simple que cela?

Non, ce n'est pas si simple. Une configuration mal configurée est ce qui rend les bases de données vulnérables et les expose aux attaquants. Il faut appliquer tous les correctifs disponibles pour la version de la base de données utilisée, et si possible exécuter la dernière version.

Je veux dire au lieu de trouver de nouvelles façons de hacher, pourquoi ne peuvent-ils pas rendre leur base de données plus sécurisée ou à l'épreuve du piratage?

Les gens continuent d'essayer de trouver de nouveaux algorithmes de hachage car des collisions sont détectées dans l'algorithme de hachage actuel. Ce n'est pas comme si nous ne parvenions pas à trouver des moyens de sécuriser les bases de données.

Pourquoi le hachage?

  1. Le hachage garantit à l'utilisateur final que ses jetons et mots de passe secrets sont stockés dans un format irréversible.

  2. Le hachage garantit que l'application qui accède à la base de données n'a pas accès aux données secrètes sous forme de texte clair.

  3. Le hachage également empêchez les données secrètes d'être exposées même aux administrateurs de bases de données et de systèmes.

Si un pirate parvient à pirater une base de données, pourquoi voudrait-il connaître les mots de passe hachés? Je veux dire qu'il peut changer d'autres colonnes de données. Par exemple, il pourrait rechercher son nom d'utilisateur et augmenter son solde bancaire. Alors, tous les champs ne devraient-ils pas être hachés?

La défiguration de la base de données cachée via les applications qui y ont accès est différente de l'effraction dans le serveur de bases de données. Si un attaquant pénètre dans le serveur hébergeant la base de données, il peut bien sûr faire tout ce qui est autorisé quel que soit le niveau de privilège auquel il a accès.

Mais ne pensez-vous pas qu'il est dangereux d'obtenir des mots de passe en texte clair, alors en une forme irréversible, car la seule possibilité qui reste à l'attaquant est de lancer la force brute passive pour trouver les mots de passe, ce qui laisse suffisamment de temps aux victimes pour changer leurs mots de passe compromis.

Vous pouvez très bien voir la différence de force des défis cryptographiques auxquels l'attaquant sera confronté pour atteindre ce hachage.

Pourquoi seuls les mots de passe sont-ils hachés?

L'authentification par mots de passe est utilisée pour prouver l'authenticité d'une entité, donc la possession d'un mot de passe suffit pour qu'un attaquant puisse se faire passer pour un autre utilisateur. Il existe donc un risque de vol d'identité s'il n'est pas haché.

Tomas Kubes
2016-10-30 23:38:39 UTC
view on stackexchange narkive permalink

Il existe des solutions qui crypte toutes les données sensibles de votre base de données, par exemple Azure. Mais la sécurité n'est pas gratuite et coûte de l'argent, du temps et vous pouvez obtenir de moins bonnes performances à cause du cryptage. Aucun déjeuner n'est gratuit.

Imaginez une boutique en ligne individuelle avec un petit budget. Cette entreprise ne peut pas se permettre une solution coûteuse. Leur choix est de choisir le moins cher ou rien. La sécurité n'est pas un choix, car vous n'avez pas d'argent pour cela. La sécurité commence à devenir importante à mesure que l'entreprise se développe.

La question parle de hachages, mais votre réponse concerne le cryptage.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...