Vaut-il la peine de chiffrer les adresses e-mail dans la base de données?

en commun avec la plupart des exigences de sécurité, vous devez comprendre le niveau de menace.

quels dommages peuvent être faits si les adresses email sont compromises?

Quelle est la chance que cela arrive?

les dommages causés si les adresses Courriel sont remplacées pourraient être beaucoup plus grands que s'ils sont exposés. Surtout si vous utilisez, par exemple, l'adresse courriel pour vérifier que le mot de passe est réinitialisé dans un système sécurisé.

la possibilité que les mots de passe soient remplacés ou exposés est très réduite si vous les hachez, mais cela dépend des autres contrôles que vous avez en place.

je me rends compte que c'est un sujet mort, mais je suis d'accord avec la logique D'Arjan derrière cela. Il y a quelques petites choses que j'aimerais faire remarquer:



Quelqu'un peut extraire des données de votre base de données sans récupérer votre code source (c.-à-d. injection SQL, tiers 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 le courriel plus privé que simple texte, En dehors de la chance quelque chose est négligé pendant une mise à jour, ou un attaquant parvient à récupérer les e-mails.

IMO: si vous prévoyez de chiffrer un courriel, stocker un hash salé de celui-ci ainsi. Ensuite, vous pouvez utiliser le hachage pour la validation, et épargner la tête de l'encryptage en permanence à l'aide de trouver une chaîne massive de données. Alors avoir une fonction privée séparée pour récupérer et déchiffrer vos e-mails lorsque vous avez besoin de les utiliser.

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

le plus gros problème est, où stockez-vous la clé de cryptage? Parce que si le hacker a un excédent à quoi que ce soit de plus que votre DB, tous vos efforts sont probablement gaspillés. (Rappelez-vous, votre application aura besoin de cette clé de cryptage pour déchiffrer et chiffrer de sorte que finalement le pirate trouvera la clé de cryptage et le schéma de cryptage utilisé).

Pro:

• une fuite de votre DB seulement n'exposera pas les adresses e-mail.

Inconvénients:

• chiffrement signifie perte de performance.
• d'Attribuer des actions de base de données sera plus difficile si pas impossible.

ne confondez pas accidentellement le cryptage avec l'obscurcissement. Nous brouillons souvent les e-mails pour prévenir le spam. Beaucoup de sites web auront "webmaster _at_ mysite.com" pour ralentir les robots d'analyse de l'adresse e-mail comme une cible potentielle de spam. Cela devrait être fait dans les modèles HTML -- il n'y a aucune valeur à faire cela dans le stockage de base de données persistante.

nous ne cryptons rien sauf si nous devons le garder secret pendant la transmission. Quand et où votre transmission de données?

1. les instructions SQL sont transmises du client au serveur; est-ce sur la même boîte ou sur une connexion sécurisée?

2. si votre serveur est compromis, vous avez une transmission involontaire. Si vous êtes inquiet à ce sujet, alors vous devriez peut-être sécuriser votre serveur. Vous avez des menaces externes ainsi que des menaces internes. Sont TOUS les utilisateurs (internes et externes) correctement authentifié et autorisé?

3. pendant les sauvegardes vous avez une transmission intentionnelle vers des supports de sauvegarde; est-ce que cela est fait en utilisant une stratégie de sauvegarde sécurisée qui chiffre comme il va?

SQL Server et Oracle (et je crois aussi d'autres DBs) prennent en charge le cryptage des données au niveau de la base de données. Si vous voulez crypter quelque chose, pourquoi ne pas simplement abstraire l'accès aux données qui pourraient être cryptées du côté du serveur de base de données et laisser l'utilisateur choisir si utiliser les données cryptées (dans ce cas, la commande SQL sera différente) ou non. Si l'utilisateur veut utiliser des données cryptées alors il peut configurer le serveur de base de données et tous les travaux de maintenance connectés avec la clé la gestion est faite à l'aide de l'outil DBA standard, fait à partir du fournisseur de PD et non de vous.

une copie de ma réponse à Quelle est la meilleure et la plus sûre façon de stocker les adresses courriel des utilisateurs dans la base de données? , juste pour la recherche...

en général, je suis d'accord avec les autres disant que cela n'en vaut pas la peine. Cependant, je ne suis pas d'accord que quiconque peut accéder à votre base de données peut probablement aussi 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 pense qu'une adresse e-mail est un détail personnel, donc je ne me soucierais pas du spam mais des conséquences personnelles quand les adresses sont révélées.

bien sûr, quand 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.

encore, pour certaines communautés en ligne les membres pourraient certainement ne pas vouloir que d'autres savent qu'ils sont un membre (comme dans le domaine des soins de santé mentale, de l'aide financière, des conseils médicaux et sexuels, du divertissement pour adultes, de la Politique, etc...). Dans ces cas, stocker le moins de détails personnels possible et crypter ceux qui sont nécessaires (notez que le cryptage au niveau de la base de données n'empêche pas les détails de montrer en utilisant L'Injection SQL), pourrait ne pas être une si mauvaise idée. Encore une fois: traiter une adresse e-mail comme tel détail personnel.

pour de nombreux sites, ce qui n'est probablement pas le cas, et vous devriez vous concentrer sur l'interdiction SELECT * FROM par L'Injection SQL, et s'assurer que les visiteurs ne peuvent pas d'une façon ou d'une autre accéder au profil personnel de quelqu'un d'autre ou aux informations de commande en changeant l'URL.

il vaut la peine de crypter les données dans les bases de données, il ne rend pas un peu plus difficile, mais bien plus difficile quand il est crypté de la bonne façon, donc arrêter la philosophie et crypter les données sensibles;)

vous avez vraiment à peser votre pire scénario senario de quelqu'un obtenir ces adresses e-mail, la probabilité de quelqu'un les obtenir, et votre effort supplémentaire/temps nécessaire pour mettre en œuvre le changement.

@Rdo

je suis un peu d'accord avec ce que vous dites, mais ne vaut-il pas la peine de crypter les données juste pour rendre un peu plus difficile pour quelqu'un de l'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.