Est-il la peine de cryptage des adresses e-mail dans la base de données?
Je suis déjà en utilisant salé hachage pour stocker les mots de passe de ma base de données, ce qui signifie que je devrais être à l'abri de table arc-en-ciel attaques.
J'ai eu une pensée, bien: que si quelqu'un s'emparer de ma base de données? Il contient les adresses de messagerie des utilisateurs. Je ne peux pas vraiment hachage, parce que je vais les utiliser pour envoyer des emails de notification, etc..
Dois-je les chiffrer?
Vous devez vous connecter pour publier un commentaire.
Bruce Schneier a une bonne réponse à ce genre de problème.
Essentiellement à crypter vos e-mails dans la base de données "au cas où" n'est pas vraiment faire la base de données de plus sûr. Où sont les clés stockées dans la base de données? Ce que les autorisations de fichier sont utilisés pour ces clés? Est la base de données accesable publiquement? Pourquoi? De quel type de compte les restrictions sont en place pour ces comptes? Où est la machine stockées, qui a un accès physique à cette boîte? Quid de la connexion distante/ssh d'accès etc. etc. etc.
Donc je suppose que vous pouvez crypter les e-mails si vous voulez, mais si c'est la mesure de la sécurité du système, puis ce n'est vraiment pas beaucoup, et serait en fait faire le travail de maintien de la base de données de plus difficile.
Bien sûr, cela pourrait faire partie d'une vaste stratégie de sécurité pour votre système - si oui, alors la la grande!
Je ne dis pas que c'est une mauvaise idée - Mais pourquoi avoir un verrou sur la porte de Blocages R'us qui a coûté 5000 $de quand ils peuvent couper à travers le contreplaqué autour de la porte? Ou entrent par la fenêtre qu'il avait laissé ouvert? Ou pire encore ils trouver la clé qui était à gauche sous le paillasson. La sécurité d'un système est seulement aussi bon que le maillon le plus faible. S'ils ont accès à la racine, puis ils peuvent très bien faire ce qu'ils veulent.
Steve Morgan fait un bon point que, même s'ils ne comprennent pas les adresses e-mail, ils peuvent encore faire beaucoup de mal (ce qui pourrait être atténué si seulement ils avaient SÉLECTIONNEZ accès)
Il est aussi important de savoir ce que vos raisons sont pour le stockage de l'adresse e-mail à tous. Je suis peut être allé un peu trop loin avec cette réponse, mais de mon point avez-vous vraiment besoin de stocker une adresse e-mail pour un compte? Le plus sécurisé des données sont des données qui n'existe pas.
Je réalise que c'est une morte sujet, mais je suis d'accord avec Arjan est la logique derrière cela. Il y a quelques choses que je voudrais souligner:
Quelqu'un peut récupérer des données à partir de votre base de données sans la récupérer votre code source (c'est à dire l'injection SQL, la troisième partie de la db). Avec cela à l'esprit, il est raisonnable d'envisager l'utilisation d'un cryptage avec une clé. Quoique, ce n'est qu'une mesure supplémentaire de sécurité, pas de sécurité...c'est pour quelqu'un qui veut garder l'e-mail de plus privé que le texte clair,
À tout hasard quelque chose est négligé pendant une mise à jour, ou un attaquant parvient à récupérer les e-mails.
OMI: Si vous prévoyez de crypter un e-mail, magasin salé de hachage de lui aussi bien. Ensuite, vous pouvez utiliser le hachage de la validation, de rechange et les frais généraux de cesse d'utiliser le chiffrement pour trouver un immense chaîne de données. Alors avoir une fonction privée pour récupérer et décrypter vos e-mails lorsque vous avez besoin de les utiliser.
En commun avec la plupart des exigences en matière de sécurité, vous avez besoin de comprendre le niveau de menace.
Ce qui peut faire des dégâts si les adresses e-mail sont compromis?
Quelles sont les chances de ce qui se passe?
Les dommages causés si les adresses emails sont REMPLACÉS pourrait être beaucoup plus grande que si elles sont EXPOSÉES. Surtout si vous êtes, par exemple, à l'aide de l'adresse e-mail pour vérifier les réinitialisations de mot de passe à un système sécurisé.
La chance de le mots de passe de l'être remplacé ou exposé est très réduit si vous hachage, mais cela dépend de ce que d'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, où voulez-vous stocker la clé de chiffrement? Parce que si le pirate dispose d'un excédent de quelque chose de plus que votre base de données, tous vos efforts sont probablement perdu. (Rappelez-vous, votre application a besoin que de la clé de cryptage à déchiffrer, chiffrer donc finalement, le hacker va trouver la clé de chiffrement et utilisés schéma de chiffrement).
Pro:
Contre:
N'avez pas accidentellement un amalgame entre le chiffrement avec de l'obscurcissement. Nous avons souvent obscurcir les e-mails pour éviter le spam. Beaucoup de sites web ont "webmaster _at_ mysite.com" pour ralentir les robots à partir de l'analyse de l'adresse e-mail comme un spam potentiel de la cible. Cela devrait être fait dans les templates HTML -- il n'y a aucun intérêt à faire cela dans la persistance de stockage de base de données.
Nous ne chiffrons pas grand-chose si nous avons besoin de garder cela secret, lors de la transmission. Quand et où vos données sont transmises?
Les instructions SQL sont transmis du client vers le serveur, est-ce sur la même case ou sur une connexion sécurisée?
Si votre serveur est compromis, vous avez une transmission accidentelle. Si vous êtes inquiet à ce sujet, alors vous devriez peut-être de la sécurisation de votre serveur. Vous avez des menaces extérieures, ainsi que les menaces internes. Sont TOUS les utilisateurs (internes et externes) correctement authentifié et autorisé?
Pendant les sauvegardes que vous avez une transmission intentionnelle de support de sauvegarde, est-ce fait à l'aide d'une sauvegarde sécurisée stratégie qui crypte comme il va?
SQL Server et Oracle (et je crois aussi que d'autres DBs) prennent en charge le cryptage des données au niveau base de données. Si vous voulez chiffrer quelque chose pourquoi ne pas simplement abstrait, l'accès aux données qui pourraient être cryptées sur le serveur de base de données côté et laissé à l'utilisateur de choisir si l'utilisation des données chiffrées (dans ce cas, la commande SQL sera différent) ou pas. Si l'utilisateur souhaite recourir à des données chiffrées, alors il peut configurer le serveur de base de données et tous les travaux reliés à la gestion des clés est faite en utilisant la norme DBA outil de, fait à partir de la DB fournisseur et non pas de vous.
Une copie de ma réponse à Quelle est la meilleure et la plus sûre façon de stocker les adresses électroniques des utilisateurs dans la base de données?, juste pour le plaisir de la recherche...
En général je suis d'accord avec les autres disent que ça n'en vaut pas la peine. Cependant, je suis en désaccord que n'importe qui peut accéder à votre base de données ne peuvent probablement obtenir vos clés. Ce n'est certainement pas vrai pour l'Injection SQL, et peut ne pas être vrai pour les copies de sauvegarde qui sont en quelque sorte perdu ou oublié. Et je ressens une adresse e-mail est un détail personnel, donc je ne se soucient pas de spam, mais sur les conséquences personnelles lorsque les adresses sont a révélé.
Bien sûr, quand vous avez peur de l'Injection SQL, alors vous devriez vous assurer que de telles injection est interdite. Et les copies de sauvegarde doivent être chiffrés eux-mêmes.
Encore, pour certaines communautés en ligne, les membres peuvent certainement veulent pas que les autres savent qu'ils sont un membre (comme liés aux soins de santé mentale, de l'aide financière, médicale et sexuelle des conseils, adulte, divertissement, politique, ...). Dans ces cas, le stockage que quelques détails que possible, et le cryptage de ceux qui sont requis (à noter que la base de données au niveau de chiffrement n'empêche pas les détails de montrer à l'aide de SQL Injection), peut-être pas une si mauvaise idée. Nouveau: traiter une adresse e-mail en tant que tel détail personnel.
Pour de nombreux sites ci-dessus n'est probablement pas le cas, et que vous devriez vous concentrer sur l'interdiction de
SELECT * FROMpar Injection SQL, et s'assurer que les visiteurs ne peuvent pas obtenir en quelque sorte à quelqu'un d'autre de profil personnel ou des informations de commande en changeant l'URL.Il vaut la peine de chiffrer les données dans des Bases de données, c'est de ne pas le rendre un peu plus difficile mais plus difficile lors de sa cryptés dans le droit chemin alors arrêtez de philosophie et de crypter les données sensibles 😉
Vous avez vraiment de peser votre pire des cas senario de quelqu'un l'obtention de ces adresses e-mail, la probabilité que quelqu'un l'obtention d'eux, et votre effort/temps nécessaire pour impliement le changement.
@Rdo
Je suis plutôt d'accord sur ce que vous dites mais n'est-il pas la peine de crypter les données juste pour le rendre un peu plus difficile pour une personne d'obtenir?
Avec votre raisonnement, il serait inutile d'avoir des verrous ou des alarmes dans votre maison, car ils peuvent aussi facilement être compromise.
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 dur que vous pouvez pour un pirate pour l'obtenir, même si elle n'est pas 100% infaillible.