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

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?

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.

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.

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.

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.

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.

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.

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 là .

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).

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.

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.

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.

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.

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.

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.

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.

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.