Est-il utile de chiffrer les adresses électroniques dans la base de données?

https://stackoverflow.com/questions/70450

09-06-2019
|

Question

J'utilise déjà hachage salted pour stocker les mots de passe dans ma base de données, ce qui signifie que je devrais être immunisé contre table arc-en-ciel attaque.

Cependant, j'avais une pensée: que se passerait-il si quelqu'un récupérait ma base de données? Il contient les adresses électroniques des utilisateurs. Je ne peux pas vraiment les hacher, car je les utiliserai pour envoyer des courriels de notification, etc.

Dois-je les chiffrer?

La solution

Bruce Schneier a une bonne réponse à ce genre de problème.

La cryptographie n’est pas la solution à vos problèmes de sécurité. Cela pourrait faire partie de la solution ou du problème. Dans de nombreuses situations, la cryptographie commence par aggraver le problème, et il n’est pas du tout clair que l’utilisation de la cryptographie constitue une amélioration.

Le cryptage de vos emails dans la base de données "au cas où" ne rendrait pas vraiment la base de données plus sécurisée. Où les clés sont-elles stockées pour la base de données? Quelles autorisations de fichier sont utilisées pour ces clés? La base de données est-elle accessible publiquement? Pourquoi? Quels types de restrictions de compte sont en place pour ces comptes? Où est stockée la machine, qui a un accès physique à cette boîte? Qu'en est-il de la connexion à distance / accès ssh, etc., etc., etc.

Donc, je suppose que vous pouvez chiffrer les courriels si vous le souhaitez, mais si tel est le degré de sécurité du système, il ne fait pas grand-chose et rendrait plus difficile la maintenance de la base de données.

Bien sûr, cela pourrait faire partie d'une politique de sécurité étendue pour votre système. Si c'est le cas, alors tant mieux!

Je ne dis pas que c'est une mauvaise idée - Mais pourquoi une serrure sur la porte de Deadlocks'R'us qui coûte 5 000 $ quand ils peuvent couper le contreplaqué autour de la porte? Ou entrer par la fenêtre que vous avez laissée ouverte? Ou pire encore, ils trouvent la clé qui a été laissée sous le paillasson. La sécurité d'un système ne vaut que par le maillon le plus faible. S'ils ont un accès root, ils peuvent pratiquement faire ce qu'ils veulent.

Steve Morgan fait bonne impression même s'ils ne comprennent pas les adresses e-mail, ils peuvent quand même faire beaucoup de mal (ce qui pourrait être atténué s'ils n'avaient qu'un accès SELECT)

Il est également important de connaître les raisons pour lesquelles vous avez enregistré l'adresse e-mail. Je suis peut-être allé un peu trop loin avec cette réponse , mais mon propos est de savoir si vous avez vraiment besoin de stocker une adresse e-mail pour un compte? Les données les plus sécurisées sont des données qui n'existent pas.

Autres conseils

Je réalise que c'est un sujet mort, mais je suis d'accord avec la logique d'Arjan. J'aimerais souligner quelques points:

Quelqu'un peut récupérer des données de votre base de données sans récupérer votre code source (c'est-à-dire injection SQL, bases de données tierces). Dans cet esprit, il est raisonnable d’envisager l’utilisation d’un chiffrement avec une clé. Bien que ce ne soit qu'une mesure de sécurité supplémentaire, pas la sécurité ... ceci est destiné à quelqu'un qui veut garder le courrier électronique plus privé que le texte en clair, Il est fort probable que quelque chose soit oublié lors d'une mise à jour ou qu'un attaquant parvienne à récupérer les emails.

IMO: Si vous envisagez de chiffrer un courrier électronique, enregistrez également un hachage salé. Ensuite, vous pouvez utiliser le hachage pour la validation et éviter la surcharge liée à l'utilisation constante du cryptage pour rechercher une chaîne de données volumineuse. Ensuite, disposez d'une fonction privée distincte pour récupérer et déchiffrer vos courriels lorsque vous en avez besoin.

Comme pour la plupart des exigences de sécurité, vous devez comprendre le niveau de menace.

Quel dommage peut être causé si les adresses électroniques sont compromises?

Quelle est la probabilité que cela se produise?

Les dommages causés si les adresses e-mail sont REMPLACÉES pourraient être beaucoup plus importants que s'ils étaient EXPOSÉS. Surtout si, par exemple, vous utilisez l'adresse e-mail pour vérifier que le mot de passe est réinitialisé sur un système sécurisé.

Les chances que les mots de passe soient remplacés ou exposés sont considérablement réduites si vous les hachez, mais cela dépend des autres contrôles en place.

Je dirais que cela dépend de l'application de votre base de données.

Le plus gros problème est de savoir où vous stockez la clé de cryptage. Parce que si le pirate informatique a plus que votre base de données, tous vos efforts sont probablement vains. (N'oubliez pas que votre application aura besoin de cette clé de chiffrement pour déchiffrer et chiffrer. Ainsi, le pirate informatique trouvera éventuellement la clé de chiffrement et le schéma de chiffrement utilisé.)

Pro:

Une fuite de votre base de données uniquement n'exposera pas les adresses électroniques.

Inconvénients:

Le chiffrement signifie une perte de performance.
L'attribution d'actions de base de données sera plus difficile, voire impossible.

Ne confondez pas accidentellement le cryptage avec l’obscurcissement. Nous masquons généralement les courriels pour empêcher le spam. Un grand nombre de sites Web auront "Webmaster _at_ mysite.com". ralentir l'analyse par les robots d'exploration en tant que cible de spam potentielle. Cela devrait être fait dans les modèles HTML - cela n’a aucune valeur de le faire dans le stockage de base de données persistant.

Nous ne chiffrons rien sauf si nous devons le garder secret pendant la transmission. Où et quand vos données seront-elles transmises?

Les instructions SQL sont transmises du client au serveur. est-ce sur la même boîte ou sur une connexion sécurisée?
Si votre serveur est compromis, vous avez une transmission non intentionnelle. Si cela vous inquiète, vous devriez peut-être sécuriser votre serveur. Vous avez des menaces externes ainsi que des menaces internes. TOUS les utilisateurs (externes et internes) sont-ils correctement authentifiés et autorisés?
Pendant les sauvegardes, vous avez une transmission intentionnelle sur un support de sauvegarde; est-ce fait avec une stratégie de sauvegarde sécurisée qui crypte au fur et à mesure?

SQL Server et Oracle (ainsi que d’autres bases de données, je crois) prennent en charge le chiffrement des données au niveau de la base de données. Si vous souhaitez chiffrer quelque chose, pourquoi ne pas résumer simplement l'accès aux données qui pourraient être chiffrées côté serveur de base de données et laisser l'utilisateur choisir d'utiliser les données chiffrées (dans ce cas, la commande SQL sera différente). Si l'utilisateur souhaite utiliser des données chiffrées, il peut configurer le serveur de base de données. Tous les travaux de maintenance liés à la gestion des clés sont effectués à l'aide d'un outil DBA standard, créé à partir du fournisseur de la base de données et non de vous.

Une copie de ma réponse à Quel est le moyen le plus sûr et le plus sûr de stocker les adresses électroniques des utilisateurs dans la base de données? , juste pour les besoins de la recherche ...

En général, je suis d’accord avec les autres pour dire que cela ne vaut pas la peine. Cependant, je ne suis pas d'accord pour dire que toute personne pouvant accéder à votre base de données peut probablement également obtenir vos clés. Ce n'est certainement pas vrai pour SQL Injection, ni pour les copies de sauvegarde perdues ou oubliées. Et j'estime qu'une adresse électronique est un détail personnel. Je ne me soucierai donc pas du spam, mais des conséquences personnelles lorsque les adresses seront révélées.

Bien sûr, lorsque vous avez peur de l’injection SQL, vous devez vous assurer que cette injection est interdite. Et les copies de sauvegarde doivent être cryptées elles-mêmes.

Néanmoins, pour certaines communautés en ligne, les membres ne voudront certainement pas que les autres sachent qu’ils sont membres (notamment en matière de santé mentale, d’aide financière, de conseils médicaux et sexuels, de divertissement pour adultes, de politique, ...). Dans ces cas, stocker le moins de données personnelles que possible et chiffrer celles qui sont requises (notez que le chiffrement au niveau de la base de données n'empêche pas l'affichage des détails à l'aide de SQL Injection), n'est peut-être pas une si mauvaise idée. Encore une fois: traitez une adresse e-mail comme un détail personnel.

Pour de nombreux sites, ce qui précède n'est probablement pas le cas et vous devez vous concentrer sur l'interdiction de SELECT * FROM via SQL Injection, et à vous assurer que les visiteurs ne puissent pas accéder au profil personnel ou aux informations de commande d'un tiers en: changer l'URL.

Cela vaut la peine de chiffrer des données dans des bases de données, cela ne rend pas les choses plus difficiles, mais bien plus difficiles quand elles sont chiffrées correctement, alors arrêtez la philosophie et cryptez les données sensibles;)

Vous devez vraiment peser votre pire scénario, celui de l’obtention de ces adresses électroniques, la probabilité que quelqu'un les obtienne, et le temps et les efforts supplémentaires que vous avez nécessaires pour implémenter le changement.

@Roo

Je suis un peu d'accord avec ce que vous dites, mais ne vaut-il pas la peine de chiffrer les données simplement pour que ce soit un peu plus difficile à obtenir?

Avec votre raisonnement, il serait inutile d’avoir des serrures ou des alarmes chez vous, car ils peuvent aussi facilement être compromis.

Ma réponse:

Je dirais que si vous avez des données sensibles que vous ne voulez pas tomber dans de mauvaises mains, vous devriez probablement le faire aussi fort que vous le pouvez pour qu'un pirate informatique les obtienne, même si ce n'est pas sûr à 100% .

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow