Pourquoi les mots de passe devraient-ils être cryptés s'ils sont stockés dans une base de données sécurisée?


78

J'ai un service web. À l'heure actuelle, les mots de passe sont stockés en texte brut dans une table MySQL sur mon serveur. Je sais que ce n'est pas la meilleure pratique, et c'est pourquoi je travaille dessus.

Pourquoi les mots de passe devraient-ils être cryptés s'ils sont stockés dans une base de données sécurisée? Je me rends compte que si quelqu'un pirate ma base de données, il obtiendra le mot de passe de tout le monde. Mais j'ai d'autres problèmes si quelqu'un entre dans ma base de données, par exemple en supprimant des données.

Le scénario auquel je peux penser est que vous êtes piraté. Vous restaurez une base de données d'il y a quelques heures et tout va bien. Cependant, si vos mots de passe sont en clair ... Le voleur a tous les mots de passe et vous devez tous les réinitialiser. Problème à vos utilisateurs.

Si les mots de passe étaient cryptés, vous pouvez simplement restaurer la base de données précédente. Est-ce correct de penser?


124
Je voudrais aller un peu plus loin. Il ne suffit pas de le chiffrer. Vous voudriez le hacher. De cette façon, vous ne devriez même pas savoir quels sont les mots de passe en clair de vos utilisateurs.
Santa

67
@Santa Le hachage du mot de passe ne suffit pas. Il faut ajouter un peu de sel pour que la recette soit assez bonne ...
Bakuriu

16
Veuillez jeter un coup d'œil à cet article de Security.StackExchange: Comment hacher des mots de passe en toute sécurité?
Adi

10
Le DBA mécontent dit ... sélectionnez * parmi l'utilisateur, puis vendez cette liste au paiement d'une indemnité de départ. Rien n'est jamais sécurisé.
Jon Raynor

Réponses:


194

Tout d'abord, vous devriez être plus libre avec des droits d'accès en lecture seule qu'en lecture-écriture. Il est possible qu'un pirate informatique ait accès à vos données mais ne puisse pas les modifier.

Mais, plus important encore, il ne s’agit pas de vous. Le fait que vous soyez foutu si quelqu'un a un accès complet à votre base de données est sans importance. Les données de vos utilisateurs sont beaucoup plus importantes .

Si vous récupérez votre base de données, le pirate informatique aura toujours accès au compte de votre utilisateur.

Et qui sait quoi d'autre? Et s'ils utilisent le même mot de passe sur Google? Ou PayPal? Que faire si un pirate informatique a accès au nom de jeune fille de sa mère ou aux 4 derniers chiffres de sa carte de crédit?

Et si cela les amène à d'autres comptes? Ne laissez pas passer un pirate informatique pour passer par un système de support utilisateur et obtenir plus d'informations .

Juste ... ne le fais pas. Ce sont des informations privées de votre utilisateur et vous n'avez pas besoin de pouvoir les voir. C'est aussi ta réputation. Cryptez-le.

EDIT: Un commentaire supplémentaire, pour éviter à tout futur lecteur de lire chaque réponse et chaque commentaire ...

Si vous voulez chiffrer (au sens le plus strict), vous devez utiliser une paire de clés publique / privée , ce qui est bien mais rend la vie un peu plus difficile pour vous et votre utilisateur.

Une solution plus simple et tout aussi efficace consiste à random-salt et hacher le mot de passe. Hacher seul ne suffit pas; Si votre utilisateur utilise un mot de passe commun, il apparaîtra dans des tables de hachage inversé, qui sont facilement disponibles avec une simple recherche sur Internet.


89
Ou mieux, hash it!
Blorgbeard

29
Cette. "J'ai d'autres problèmes si quelqu'un entre dans ma base de données". C'est votre base de données, vous vous attendez à avoir des problèmes si elle est piratée. Mais en stockant des mots de passe en clair, vous posez des problèmes à tous vos utilisateurs, éventuellement à tous leurs autres comptes. À votre avis, combien de personnes utilisent réellement un mot de passe différent sur chaque site Web?
Carson63000

13
Suivez le conseil de Blorgbeard, lisez ceci . Le cryptage des mots de passe ne fournit pas de protection lorsque votre serveur Web a été compromis. La clé pour déchiffrer les mots de passe doit être stockée quelque part sur le serveur. Le hachage des mots de passe signifie que même dans le cas où une personne a un accès complet à la machine, elle ne peut pas récupérer les mots de passe facilement.
Slicedpan

7
Pourquoi devriez-vous jamais avoir besoin de chiffrer les mots de passe si cela ne donne aucune valeur à votre système? À quel moment devrez-vous déchiffrer les mots de passe, à des fins autres que la comparaison? @pdr, vous ne devriez pas dire au PO de chiffrer, vous devriez lui dire de saler et de hacher.
NobleUplift

4
Vous souhaitez également hacher les réponses à leurs questions de récupération de mot de passe. Sinon, ils peuvent également être utilisés pour accéder à d'autres sites, tout comme les mots de passe.
Zan Lynx

64

Si vous êtes piraté, vous pouvez restaurer le site à partir de sauvegardes et le réparer. Mais le pirate informatique a toujours des mots de passe pour les comptes de tous! Il existe des exemples concrets de ce type d'événements (Sony, Linked-in) dans lesquels, si les tables de mots de passe avaient été correctement hachées et salées, sécuriser et restaurer rapidement le service aurait été beaucoup plus simple.

C'est probablement une bonne idée de supposer que vous allez être piraté, de concevoir votre stratégie de sauvegarde et de chiffrer les données sensibles en gardant à l'esprit cette hypothèse. Et ce ne sont pas que des pirates informatiques contre lesquels vous devez vous protéger. Les employés mécontents, malhonnêtes ou simplement inconscients pourraient donner des mots de passe en clair.

Sans hachage, vous devrez désactiver l'accès pour tous jusqu'à ce qu'ils changent leur mot de passe (ce qui, même si possible, sera un casse-tête énorme pour tout le monde). Si les mots de passe avaient été hachés et salés, vous pourriez restaurer le service Web et il serait beaucoup plus difficile pour un attaquant d'accéder aux comptes d'utilisateurs.

Un mot de passe correctement haché et salé est fondamentalement à sens unique. Vous ne pouvez pas facilement deviner le mot de passe à partir du mot de passe haché. Même vous, en tant que prestataire de services, ne pourrez pas le deviner, vous ne pourrez que le réinitialiser.

En outre, comme Elin l'a dit, n'essayez pas de lancer votre propre hachage (ou chiffrement). Utilisez une bibliothèque standard.



13
+1 pour avoir mentionné des employés mécontents. Il est facile de l'ignorer lorsque vous êtes un magasin à personne ou une petite entreprise, mais vous finirez par avoir des personnes qui travaillent avec les données que vous n'avez pas personnellement vérifiées.

2
Ecrire le foreach pour parcourir une liste d'utilisateurs puis hacher leurs mots de passe est un travail de quelques minutes et franchement 4000 n'est presque rien. php.net/manual/fr/function.hash.php
Elin

3
Vous continuez à basculer entre les termes "chiffrer" avec "hachage et sel" @ david25272. Ne confondez pas les deux, qui sont entièrement différents. Maintenant, l'OP recherche un algorithme de chiffrement et non un algorithme de hachage. En outre, c'est "sel et hasch", pas "hasch et sel". Vous ne pouvez pas saler après votre hasch.
NobleUplift

1
Également @phpmysqlguy, lisez ma réponse pour des suggestions sur les algorithmes de salage et de hachage .
NobleUplift

36

Mais j'ai d'autres problèmes si quelqu'un entre dans ma base de données, par exemple en supprimant des données.

Il ne s'agit pas des problèmes que vous avez, mais des problèmes que cela pourrait causer à tous vos autres utilisateurs. Il s'agit d'éliminer la tentation (ou pire, la responsabilité potentielle) des personnes travaillant sur le site d'abuser des données qui y sont stockées.

Vous voyez, même si les gens doivent utiliser des mots de passe différents sur des systèmes différents, la réalité est que non .

... et puisqu'il est si facile de hacher les mots de passe, vous n'avez aucune excuse pour ne pas suivre les meilleures pratiques de l'industrie.


9
Vous faites ce que je pense être le point le plus important: VOUS et vos travailleurs ne devriez pas avoir accès au mot de passe de l'utilisateur. Qui se soucie du pirate informatique, ce sont les personnes qui détiennent les données qui concernent les utilisateurs.
Adam Davis

1
+1 pour le fait qu'en tant que développeur / admin, vous ne devriez pas avoir accès aux mots de passe de vos utilisateurs. C'est en soi une raison suffisante.
Matt

21

Les attaques remarquables, telles que la suppression de données, appartiennent généralement à des amateurs et sont le moindre de vos soucis. Une des premières choses qu'un attaquant expérimenté fera est de tenter d'obtenir un accès légitime. Ainsi, même si vous corrigez la vulnérabilité d'origine qu'il a utilisée, il pourra toujours y accéder. Il fera tout son possible pour éviter d'attirer l'attention sur lui-même jusqu'à ce qu'il accomplit ce qu'il désire. En laissant les mots de passe intact, vous avez potentiellement rendu son travail beaucoup plus facile. Vous avez également rendu plus difficile la détection et l’isolation de son comportement malveillant futur.

En outre, tous les compromis ne vous donnent pas un accès complet au shell. Que faire si la vulnérabilité utilisée par un attaquant est simplement une injection SQL en lecture seule sur la userstable? Laissant les mots de passe sans entrave lui a simplement donné un accès presque complet.

Cela s'ajoute aux raisons données par d'autres réponses concernant votre responsabilité de protéger les données de vos utilisateurs. Mon point est que ce ne sont pas seulement vos utilisateurs qui ont quelque chose à perdre.


18

Je dois poster une réponse ici sur une erreur dans la question elle-même. Vous demandez si les mots de passe doivent être cryptés. Personne ne chiffre les mots de passe. personne, à l'exception des services et programmes tels que Firefox Sync et Roboform, dont le seul but est de chiffrer les mots de passe.

Jetons un coup d'oeil aux définitions:

En cryptographie, le cryptage consiste à coder des messages (ou informations) de manière à ce que seules les personnes autorisées puissent le lire.

Et hachage:

Une fonction de hachage est un algorithme qui mappe des données de longueur arbitraire à des données de longueur fixe.

En d'autres termes, le cryptage est une conversion bidirectionnelle et le hachage est une conversion unidirectionnelle . Par conséquent, à moins que vous ne décryptiez pour les afficher plus tard, il ne s'agit pas d'un cryptage.

En outre, ne faites pas que du hasch, sel ! Lisez cette page avant de hacher vos mots de passe.

En ce qui concerne les algorithmes de hachage, sur lesquels le PO se penche actuellement, je suggérerais n'importe lequel des variantes SHA-2 haut de gamme, tels que SHA-384 ou SHA-512.

Et assurez-vous d'utiliser des tours de hachage . Ne pas hacher une fois, hacher plusieurs fois.

Pensez à lire cette page pour sécuriser davantage votre processus de connexion.

Deuxièmement, votre base de données ne peut jamais être suffisamment sécurisée. Il y aura toujours des failles de sécurité et des risques en constante évolution. Vous devez suivre la loi de Murphy et toujours vous préparer à la pire éventualité.

Les autres points soulevés par pdr correspondent exactement à ce que je dirais: personnes utilisant le même mot de passe pour tous les sites Web, pirates utilisant l'ingénierie sociale pour obtenir plus d'informations, etc.


+1 pour le hash plus le sel. Casser des hash sans sels est trop facile.
Code Maverick

3
Vous savez ce qu'il y a de l'autre côté d'une table arc-en-ciel @CodeMaverick? Un pot d'or.
NobleUplift

Dans le contexte du hachage de mot de passe, MD5 ne présente aucune vulnérabilité connue, à part être rapide, et cela s'applique également à SHA-2. Utiliser une construction lente et itérée est bien plus important que de choisir SHA-2 plutôt que MD5.
CodesInChaos

4
"Lisez cette page avant de hacher vos mots de passe" - cette page indique que vous ne devez pas utiliser de cycles de hachage, mais une méthode de hachage spécialement conçue pour être aussi lente que nécessaire, telle que PBKDF2.
jhominal

2
Utilisez SCrypt ou PBKDF2, les deux étant conçus pour être très coûteux à exécuter en termes de mémoire ou de processeur. Utilisez un sel généré aléatoirement que vous stockez dans la fiche de l'utilisateur. N'effectuez pas plusieurs cycles de hachage, cela entraînerait simplement des problèmes de collision.
tom.dietrich

14

Il y a un principe important en jeu ici. Il n'y a qu'une seule personne qui a une entreprise connaissant le mot de passe d'un utilisateur. C'est l'utilisateur. Pas leur femme / mari, leur médecin ou même leur prêtre.

Cela n'inclut certainement pas le programmeur, l'administrateur de la base de données ou le technicien système responsable du service qu'ils utilisent. Cela crée un défi, car le programmeur a la responsabilité de recevoir la preuve que l'utilisateur connaît réellement le mot de passe, ce qui est un problème non trivial à résoudre de manière pure.

La solution pure consiste à mettre en place un mécanisme selon lequel l’utilisateur est mis au défi avec des données nouvelles et imprévisibles, puis doit renvoyer une réponse basée sur ces données et leur mot de passe. Une implémentation de ceci consisterait à demander à l'utilisateur de signer numériquement certaines données nouvellement générées avec leur signature numérique, et nous pourrions prouver mathématiquement qu'ils utilisaient la même paire de clés cryptographiques qu'ils avaient utilisée pour créer le compte à l'origine.

En pratique, les solutions pures nécessitent une infrastructure et un traitement substantiels du côté client, ce qui n'est souvent pas approprié pour de nombreux sites Web pour les données à protéger.

Une solution plus commune serait:

Au moment où un mot de passe est reçu pour la première fois dans l'application, il est transmis à la fonction de hachage, avec la valeur "sel" aléatoire de l'application dans la fonction de hachage.

La chaîne d'origine est alors écrasée en mémoire et à partir de ce moment, le hachage salé est stocké dans la base de données ou comparé à l'enregistrement de la base de données.

Les principaux aspects de la sécurité sont les suivants:

  1. La connaissance du hachage ne fournit pas directement d'authentification.
  2. Le calcul inverse du mot de passe à partir du hachage n'est pas pratique.
  3. L'utilisation de tables arc-en-ciel (longues listes de mots de passe et leurs hachages calculés) est rendue plus ardue car le hachage résultant dépend à la fois du nom d'utilisateur et du mot de passe.

6
En général, il est préférable d'utiliser un sel aléatoire au lieu du nom d'utilisateur.
CodesInChaos

Wow, bonne prise @CodesInChaos. Je ne l'avais pas remarqué lors de ma première lecture de la question. Oui, votre sel devrait être généré de manière aléatoire. Il n'est pas nécessaire que ce soit un blob fou stocké dans MySQL (et ce serait dommage car il ne serait pas portable). Sinon, +1 pour indiquer que seul l'utilisateur doit connaître le mot de passe de l'utilisateur.
NobleUplift

Ok, réponse mise à jour pour suggérer que l'application a sa propre valeur de sel aléatoire.
Michael Shaw

4
Non, l'application n'a pas une valeur de sel soit. Il devrait y avoir une valeur de sel différente, fortement aléatoire, pour chaque hachage stocké. (Vous stockez le sel à côté de ce hachage.) C'est ce qui protège des attaques statistiques. Si vous avez utilisé le même hachage pour l'ensemble de l'application, le même texte en hachage a la même valeur. C'est bien pire que d'utiliser le nom d'utilisateur comme hash.
Ben Voigt le

Ce n'est pas un service Web, mais l'authentification par paire de clés SSH utilise la solution «pure», dans laquelle le serveur stocke une clé publique et que l'utilisateur s'authentifie avec une clé privée.
cpast le

10

Vous devez "chiffrer" (en fait, "hachage", pour une bonne notion de hachage) les mots de passe en tant que deuxième couche de défense : ceci est destiné à empêcher un attaquant, qui n'a qu'un aperçu en lecture seule de la base de données, d'escalader cela en accès en lecture-écriture et, précisément, commence à modifier les données. Les violations partielles en lecture seule se produisent dans le monde réel, par exemple via une attaque par injection SQL à partir d'un compte avec un accès en lecture seule, ou en récupérant un disque dur mis au rebut ou une ancienne bande de sauvegarde à partir d'un conteneur de dépôt. J'ai longuement écrit sur ce sujet .

Pour plus d'informations sur les méthodes de hachage des mots de passe, voir cette réponse . Cela implique des sels, des itérations et, surtout, ne pas inventer vos propres algorithmes (la cryptographie maison est une recette sûre pour un désastre).


+1 pour connaître la différence entre cryptage et hachage.
NobleUplift

8

Je ne répéterai pas ce que d'autres personnes ont dit, mais en supposant que vous disposiez de PHP 5.3.8 ou supérieur, vous devriez utiliser le langage PHP natif bcryptpour stocker vos mots de passe. Ceci est intégré à PHP. Si vous avez PHP 5.5, vous pouvez utiliser la meilleure constante de mot de passe disponible. Vous pouvez également utiliser une bibliothèque pour que 5.3.8 ou mieux se comporte comme 5.5.

Stack Overflow question Comment utilisez-vous bcrypt pour le hachage de mots de passe en PHP? explique, et les autres réponses là expliquent plus. S'il vous plaît ne plaisante pas d'essayer de le faire vous-même.


2
Malheureusement, j'utilise PHP 5.3.3 pour que vos suggestions ne
soient

4
5.3.3 à 5.3.8 représente-t-il vraiment une mise à niveau?
gbjbaanb

Avez-vous une chance d'être sur Red Hat? Parce qu'ils ont rétroporté le correctif vers bcrypt. Sinon, utilisez SHA256 au lieu de brcypt.
Elin

1
Le cryptage et le hachage sont des choses différentes. Hachez les mots de passe, ne les chiffrez pas. Vous n'avez jamais besoin de les connaître. Vous devez seulement que l'utilisateur puisse utiliser le mot de passe pour prouver qui il est. Le hachage (avec du sel) le permet. Cryptage, en particulier Le chiffrement symétrique est incorrect car il permet de récupérer les mots de passe.
Paul de Vrieze

La seule chose que je vais ajouter, c'est que la bonne chose à propos de la fonction password_hash () dans PHP 5.5+ est qu'elle gère le salage et ainsi de suite, de manière saine. Avant cela, vous devez utiliser quelque chose comme la bibliothèque de ircmaxell qui la rétrograde (il a écrit l'implémentation 5.5). Ne présumez pas que vous pouvez générer un sel aléatoire par vous-même. C'est très très difficile et il vaut mieux le laisser à des experts. il est très facile d'obtenir des résultats aléatoires mais non uniformes et exploitables.
Elin

7

Je suis d'accord avec la réponse de pdr, pour les raisons indiquées dans cette réponse.

J'ajouterais ce qui suit: vous devriez le faire car c'est facile à faire et généralement accepté comme meilleure pratique pour toute application. Plus spécifiquement, les mots de passe doivent toujours être salés et hachés avant d'écrire dans un stockage persistant. Voici une bonne référence sur l'importance de saler et de choisir un bon hachage cryptographique (qui fournit également du code source gratuit dans plusieurs langues populaires): https://crackstation.net/hashing-security.htm

Le peu de temps de développement supplémentaire vaut bien la protection offerte à vos utilisateurs et à votre réputation de développeur.


+1 pour parler à la fois le salage et le hachage, ainsi que ne pas mentionner le chiffrement, qui ne fait même pas dans cette question.
NobleUplift

2

Le scénario auquel je peux penser est que vous êtes piraté.

Un autre scénario auquel vous devez penser: quelqu'un a glissé votre DBA (ou toute autre personne pouvant exécuter des requêtes sélectionnées sur votre base de données) à 100 USD, afin de leur donner les mots de passe des utilisateurs. Ou ingénieurs sociaux certains stagiaires pour le faire.

Ensuite, ils utilisent ces mots de passe pour se connecter au site Gmail ... ou au site de commerce de l'utilisateur ... (car les utilisateurs sont ... mal avisés - et utilisent le même mot de passe sur plusieurs sites).

Ensuite, l'utilisateur en colère poursuit votre société pour avoir révélé son mot de passe.


PERSONNE (y compris les personnes de votre entreprise) ne devrait pouvoir lire le mot de passe en clair. Déjà. Il n'y a aucun besoin commercial ou technique légitime pour cela.


2

D'une part, même les administrateurs de base de données ne devraient pas voir les mots de passe des utilisateurs. Cela les empêchera au cas où l'administrateur déciderait de consulter un mot de passe et de se connecter au compte de leurs utilisateurs.


1
cela n'ajoute rien à ce qui a déjà été posté dans les réponses précédentes
gnat

3
+1 Il a en fait dit "hachage", au lieu du cryptage comme beaucoup d'autres. En outre, il a directement contredit le PO qui a déclaré qu'il souhaitait que les mots de passe en texte clair se connectent aux comptes d'autres utilisateurs.
NobleUplift

0

C'est surprenant que personne ne l'ait mentionné pour le moment, mais qu'en est-il de la sécurité physique de votre base de données?

Vous disposez peut-être de la meilleure sécurité informatique au monde, mais cela n’empêche personne de pouvoir accéder physiquement à votre support de stockage. Que se passe-t-il lorsque votre équipe gagne le Superbowl cet après-midi et qu'une petite émeute éclate dans le centre-ville de votre ville où se trouve votre bureau / fournisseur d'hébergement? (Étant donné qu'il s'agit de Seattle vs Denver, deux grands domaines informatiques aux États-Unis, je ne pense pas que ce soit déraisonnable). La foule envahit votre immeuble et, tandis que les autorités sont débordées, une partie de votre matériel est saisie avec une base de données contenant des mots de passe en texte clair.

Que se passe-t-il lorsque les fédéraux se présentent et s'emparent de votre équipement, car un cadre supérieur utilisait son poste au sein de la société pour exécuter des transactions boursières illégales? Ensuite, les fédéraux utilisent ces mots de passe pour enquêter sur vos clients, bien qu’ils n’aient rien fait de mal. Puis ils réalisent que c'est VOUS qui les avez laissés vulnérables.

Que se passe-t-il lorsque votre service informatique oublie d'effacer les anciens disques RAID contenant votre base de données lorsqu'il effectue des remplacements planifiés avant de "distribuer" les anciens disques aux stagiaires, puis que leurs colocataires du dortoir trouvent ce qui a été laissé et qu'ils peuvent le faire " "le vendre" et ne jamais le leur faire remonter?

Que se passe-t-il lorsque votre serveur de base de données envoie une carte mère, que le service informatique restaure une image sur votre nouveau serveur et que la "carcasse" de l'ancien serveur est renvoyée dans le tas de recyclage? Ces disques sont toujours bons et ces données sont toujours là.

Tout bon architecte sait que la sécurité n’est pas quelque chose que vous «verrouillez» plus tard avec des pare-feu et des stratégies d’exploitation. La sécurité doit être un élément fondamental de la conception dès le début, ce qui signifie que les mots de passe sont à hachage unidirectionnel, ne sont JAMAIS transmis sans cryptage (même à l'intérieur de vos propres centres de données) et ne sont jamais récupérables. Tout ce qui peut être récupéré peut être compromis.


-1

Abstraction faite du piratage de votre base de données: en tant que client, je ne voudrais pas que vous connaissiez mon mot de passe. Je sais que vous pouvez facilement attraper le mot de passe quand il arrive à la demande, mais j'ai un meilleur pressentiment quand vous ne l'avez pas à votre disposition pour interroger quand vous le souhaitez.


1
En fait, si le PO allait plus loin et était crypté en JavaScript, le hachage serait alors envoyé par fil et ne figurerait jamais dans la demande.
NobleUplift

1
Dans ce cas, un attaquant n'aurait plus qu'à envoyer le hachage sur le fil également. Le hachage fonctionnerait simplement comme un mot de passe sophistiqué mais non crypté, n'est-ce pas? (Edit: pas si il fallait saler avec un sel différent à chaque fois, et le sel venait du serveur. Je pense)
RemcoGerlich

1
@RemcoGerlich Le concept clé est connu sous le nom de nonce utilisé pour éviter une attaque par rejeu .

-1

Si les mots de passe sont stockés en texte brut, cela signifie qu'ils sont connus de l'utilisateur et de quiconque a accès à cette table. L’idée de mettre en œuvre des utilisateurs et des mots de passe est d’assurer qu’une certaine session de votre système appartient à ladite personne, pour des raisons de confidentialité et de sécurité.

Si un groupe de personnes connaît un nom d'utilisateur / mot de passe, il devient inutile d' identifier une personne sans équivoque , ce qui crée de nombreux scénarios possibles de vol d'identité, de fraude ...

C'est pourquoi les mots de passe sont stockés à l'aide de protocoles de chiffrement asymétriques, ce qui vous permet de les valider sans pouvoir les lire.


2
Qui stocke les mots de passe en utilisant le cryptage asymétrique? C'est une cryptographie à clé publique, ce qui signifie que même après le cryptage de mon mot de passe, il peut être déchiffré et lu si quelqu'un obtient ma clé privée. Avec le hachage, moi et moi seul connaissons mon mot de passe (à moins que je ne l’écrive ou que je le mette dans un gestionnaire de mots de passe, où il s’agit d’un cryptage asymétrique).
NobleUplift

Consultez la page wikipedia pour la cryptographie à clé publique: fr.wikipedia.org/wiki/Public-key_cryptography "Cryptographie à clé publique, également connue sous le nom de cryptographie asymétrique,"
Alpha1983,

2
... oui, j'ai dit ça using asymmetric encryption? That's public-key cryptography. Où veux-tu en venir?
NobleUplift

-1

Je pense qu'il y a un défaut fondamental dans la question. Le fait est qu’il n’existe pas de "base de données sécurisée". Cela devrait être pris pour acquis qu'il existe des failles dans votre système quelque part qui pourraient permettre à des utilisateurs malveillants d'accéder à des données arbitraires sur vos serveurs. Heartbleed est un excellent exemple. Il s'agit d'un exploit qui avait été sauvage pendant plus de deux ans avant d'être remarqué par les chercheurs. Vous avez peut-être fait tout ce que vous savez faire pour protéger les données, mais vous ne pouvez pas rendre compte de tous les autres logiciels que vous utilisez sur vos serveurs et de la complexité de leurs interactions.

Si quelqu'un s'intéresse à vous, vous serez piraté. Il est important de faire de votre mieux pour éviter de se faire pirater en premier lieu, mais également pour atténuer les dommages causés lorsque cela se produit en mettant en place autant d'obstacles que possible. Hachez vos mots de passe. Ce n’est pas si difficile à mettre en place, et vous rendez un mauvais service à vos utilisateurs en ne prenant pas au sérieux leur vie privée. C'est une honte de penser que vous êtes en quelque sorte mieux protégé contre les attaques malveillantes que des entreprises comme Yahoo , Sony ou Target , qui ont toutes été piratées.


1
cela ne semble rien offrir de substantiel sur plus de 14 réponses précédentes
gnat

Je ne suis pas d'accord sinon je ne l'aurais pas posté. Je ne suis pas sûr de voir en quoi vos commentaires négatifs ajoutent à la conversation, à part décourager les gens de participer.
lobati

Eh bien, je ne sais pas si vous avez lu d’autres réponses avant d’afficher la vôtre, mais toutes les remarques que je viens de lire ont déjà été faites (et ma lecture est mieux présentée) ailleurs. Par exemple, le point sur les défauts de la question a été fait il y a plus de 2 mois dans cette et cette réponse. On a parlé d'au moins 7 autres réponses concernant le hachage des mots de passe. Il y a longtemps, il a également été question de faire des sauvegardes et de comptabiliser les problèmes éventuels dans d'autres éléments du système. Etc etc
Gnat

Le point d'erreur lié était différent du mien. Ils affirmaient la différence de sens entre le hachage et le cryptage, alors que je disais que c'était une erreur de penser qu'une base de données pouvait être considérée comme "sécurisée". Je ne vois toujours pas d'autres réponses traitant des autres logiciels et de leurs interactions peu sûres, et je n'ai rien dit sur les sauvegardes.
lobati

"suppose que vous allez être piraté" - c'est ainsi que cela a été écrit dans une réponse publiée il y a plus de 2 mois
gnat
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.