Pourquoi les mots de passe devraient-ils être chiffrés s'ils sont stockés dans une base de données sécurisée?
J'ai un service web. En ce moment, j'ai des mots de passe 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 j'y travaille.
Pourquoi les mots de passe devraient-ils être chiffré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 texte brut ... Le voleur a tous les mots de passe et vous devez tous les réinitialiser. Tracas à vos utilisateurs.
Si les mots de passe ont été chiffrés, vous pouvez simplement restaurer la base de données précédente. Est-ce la bonne pensée?
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 ait accès à vos données mais ne soit pas en mesure de les modifier.
Mais, plus important encore, cela ne vous concerne pas. Le fait que vous puissiez être foutu si quelqu'un a un accès complet à votre base de données n'a pas d'importance. Les données de vos utilisateurs sont beaucoup plus importantes.
Si vous récupérez votre base de données, le pirate a toujours accès à votre compte utilisateur.
Et qui sait quoi d'autre? Et s'ils utilisent le même mot de passe chez Google? Ou PayPal? Et si cela permet à un pirate d'accéder au nom de jeune fille de sa mère ou aux 4 derniers chiffres de sa carte de crédit?
Et si cela les place sur d'autres comptes? Ne passez pas devant un pirate pour passer par un système de support utilisateur et obtenir plus d'informations .
Juste ... juste pas. Ce sont les informations privées de votre utilisateur et vous n'avez pas besoin de les voir. C'est aussi votre réputation. Chiffrez-le.
EDIT: Un commentaire supplémentaire, pour éviter à tout futur lecteur de lire chaque réponse et commentaire ...
Si vous allez crypter (au sens 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 hash le mot de passe. Le hachage seul ne suffit pas; si votre utilisateur utilise un mot de passe commun, il apparaîtra dans des tableaux 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 corriger. Mais le pirate a toujours des mots de passe pour les comptes de tout le monde! Il existe des exemples concrets de ce qui se passe (Sony, Linked-in), où si les tables de mots de passe avaient été correctement hachées et salées, sécuriser et restaurer le un service rapide aurait été beaucoup plus facile.
C'est probablement une bonne idée de supposer que vous allez être piraté, et de concevoir votre stratégie de sauvegarde et de crypter toutes les données sensibles avec cette hypothèse à l'esprit. Et ce ne sont pas seulement les pirates contre lesquels vous devez vous protéger. Des employés mécontents, malhonnêtes ou simplement désemparés pourraient donner des mots de passe en texte brut.
Sans hachage, vous devrez désactiver l'accès pour tout le monde jusqu'à ce qu'ils changent leur mot de passe (ce qui, même si possible, sera un énorme casse-tête 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 des gens.
Un mot de passe correctement haché et salé est essentiellement à sens unique. Vous ne pouvez pas facilement deviner le mot de passe à partir du mot de passe haché. Même vous, comme le fournisseur de services ne pourra pas le deviner, vous ne pouvez que le réinitialiser.
De plus, 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, c'est-à-dire la suppression de 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 de supprimer la tentation (ou pire encore, la responsabilité potentielle) pour les personnes travaillant sur le site d'abuser des données qui y sont stockées.
Voir, même si les gens devraient utiliser différents mots de passe sur différents systèmes, la réalité est que ne pas.
... et comme 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 notables comme la suppression de données sont généralement l'affaire des amateurs et sont le moindre de vos soucis. L'une des premières choses qu'un attaquant expérimenté fera sera de tenter d'obtenir un accès légitime, donc même si vous corrigez la vulnérabilité d'origine qu'il a utilisée, il pourra toujours y entrer. Il fera tout son possible pour éviter d'attirer l'attention sur lui jusqu'à ce qu'il accomplit ce qu'il désire. En laissant les mots de passe sans hachage, vous avez simplement rendu son travail beaucoup plus facile. Vous avez également rendu plus difficile la détection et l'isolement de son futur comportement malveillant.
De plus, tous les compromis ne vous donnent pas un accès complet à Shell. Et si la vulnérabilité utilisée par un attaquant n'était qu'une injection SQL en lecture seule sur la table users? Laisser les mots de passe sans hachage lui a donné à peu près un accès 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 des programmes comme Firefox Sync et Roboform, dont le seul but est de crypter les mots de passe.
Jetons un coup d'œil aux définitions:
En cryptographie, le cryptage est le processus de codage des messages (ou informations) de telle manière que seuls les tiers autorisés peuvent 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 chiffrement est une conversion bidirectionnelle et le hachage est une unidirectionnelle conversion, donc à moins que vous ne déchiffriez pour les voir plus tard, ce n'est pas du chiffrement.
Aussi, ne faites pas que du hachage, du sel ! Lisez cette page entière avant de hacher vos mots de passe.
En ce qui concerne les algorithmes de hachage, que l'OP examine actuellement, je suggérerais l'une des variantes SHA-2 haut de gamme, telles que SHA-384 ou SHA-512.
Et assurez-vous d'utiliser tours de hachage . Ne hachez pas une fois, hachez 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 sont exactement ce que je dirais d'autre: les gens qui utilisent le même mot de passe pour chaque site Web, les pirates utilisant l'ingénierie sociale pour obtenir plus d'informations, etc. 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 des utilisateurs. Voilà l'utilisateur. Pas leur femme/mari, leur médecin ou même leur prêtre.
Il 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 est d'avoir un mécanisme où l'utilisateur est confronté à des données nouvelles et imprévisibles, puis doit retourner une réponse basée sur ces données et leur mot de passe. Une implémentation de cela 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 ont utilisé la même paire de clés cryptographiques qu'ils ont utilisée pour créer à l'origine le compte.
Dans la pratique, les solutions pures nécessitent une infrastructure et un traitement côté client importants, et pour de nombreux sites Web, cela n'est souvent pas approprié pour les données protégées.
Une solution plus courante serait:
Au moment où un mot de passe est reçu pour la première fois dans l'application, le mot de passe est transmis à la fonction de hachage, avec la valeur aléatoire de "sel" de votre application dans la fonction de hachage.
La chaîne d'origine est ensuite é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 base de données.
Les aspects clés qui assurent la sécurité sont les suivants:
- La connaissance du hachage ne fournit pas directement l'authentification.
- Le calcul inverse du mot de passe à partir du hachage est impossible.
- L'utilisation de tables Rainbow (longues listes de mots de passe et leurs hachages calculés) est rendue plus difficile 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 comme deuxième couche de défense : cela signifie pour empêcher un attaquant, qui a eu un aperçu en lecture seule de la base de données, de l'intensifier en accès en lecture-écriture et, précisément, de commencer à modifier les données. Des 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 accès en lecture seule, ou en récupérant un disque dur jeté ou une ancienne bande de sauvegarde à partir d'une benne à ordures. J'ai longuement écrit sur ce sujet là .
En ce qui concerne les bonnes façons de hacher les mots de passe, voir cette réponse . Cela implique des sels, des itérations et, surtout, 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 les autres ont dit, mais en supposant que vous avez PHP 5.3.8 ou mieux, vous devriez utiliser le PHP native bcrypt pour stocker vos mots de passe. Il 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 un bibliothèque pour faire 5.3.8 ou mieux se comporter comme 5.5.
Stack Overflow question Comment utilisez-vous bcrypt pour hacher les mots de passe en PHP? l'explique, et les autres réponses expliquent plus. S'il vous plaît, ne vous embêtez pas à 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 il 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 sur 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 qu'il offre à vos utilisateurs et à votre réputation de développeur.
D'une part, même les administrateurs de base de données ne devraient pas voir les mots de passe des utilisateurs. Les hacher les empêchera au cas où l'administrateur déciderait de regarder un mot de passe et de se connecter au compte de leurs utilisateurs.
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 qui que ce soit d'autre peut exécuter certaines requêtes sur votre base de données) 100 $, pour leur donner les mots de passe des utilisateurs. Ou des ingénieurs sociaux, un stagiaire pour le faire.
Ensuite, ils utilisent ces mots de passe pour se connecter à Gmail de l'utilisateur ... ou au site de commerce ... (parce que les gens sont ... moins intelligents dirons-nous - et utilisent le même mot de passe sur tous les sites).
Ensuite, l'utilisateur furieux poursuit votre entreprise pour avoir divulgué son mot de passe.
PERSONNE (y compris les personnes de votre entreprise) ne devrait pouvoir lire le mot de passe en texte brut. Déjà. Il n'y a aucun besoin commercial ou technique légitime pour cela.
Eh bien, il est surprenant que personne ne l'ait encore mentionné, 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 pas quiconque peut accéder physiquement à vos supports de stockage. Que se passe-t-il lorsque votre équipe remporte 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é que c'est Seattle vs Denver, deux grands domaines informatiques aux États-Unis, je ne pense pas que ce soit déraisonnable). La foule s'infiltre dans votre immeuble et alors que les autorités sont débordées, quelqu'un attrape une partie de votre matériel 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 saisissent votre équipement parce qu'un cadre de haut niveau utilisait sa position dans l'entreprise 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 a rendus vulnérables.
Que se passe-t-il lorsque votre service informatique oublie d'effacer les anciens disques RAID qui contenaient votre base de données lorsqu'ils effectuent des remplacements planifiés avant de "distribuer" les anciens disques aux stagiaires, puis leurs colocataires de dortoir trouvent ce qui reste, et découvrent qu'ils peuvent " le vendre "et ne jamais le retrouver?"
Que se passe-t-il lorsque votre serveur DB fait exploser une carte mère, le service informatique restaure une image sur votre nouveau serveur et la "carcasse" de l'ancien serveur est jetée dans le tas de recyclage? Ces disques sont toujours bons et ces données sont toujours là.
Tout architecte décent sait que la sécurité n'est pas quelque chose que vous "verrouillez" plus tard avec des pare-feu et des politiques d'exploitation. La sécurité doit être une partie fondamentale de la conception dès le début, ce qui signifie que les mots de passe sont hachés dans un sens, [~ # ~] jamais [~ # ~] transmis sans cryptage (même à l'intérieur de vos propres centres de données), et jamais récupérable. Tout ce qui peut être récupéré peut être compromis.