Crypter les adresses e-mail en php
Je crée un site Web et j'essaie de trouver un moyen de crypter les adresses e-mail de l'utilisateur. Ce serait bien si, en cas de vol de ma base de données, les e-mails de mes utilisateurs n'étaient pas en texte brut. J'ai pensé que l'utilisateur avait besoin de l'e-mail pour se connecter, donc si je le crypte avec son mot de passe comme clé, ou même l'e-mail lui-même, je pourrais toujours créer une fonction de connexion, qui fonctionnerait.
Le problème vient de la situation où j'ai besoin de l'adresse e-mail de l'utilisateur. Par exemple, dans une situation de réinitialisation de mot de passe ou d'envoi d'une newsletter. Je pourrais avoir un deuxième champ dans la base de données avec l'adresse e-mail de l'utilisateur, crypté avec une clé que je connais.
Puis-je crypter quelque chose, où deux clés fonctionnent? Comme une clé principale ..... ou suis-je stupide?
Si vous n'avez besoin de vérifier l'e-mail que lorsque l'utilisateur le fournit, hachez-le, comme suggère vidarlo , de la même manière que vous hacheriez un mot de passe. Pas besoin de chiffrement ici. Le revers de cette approche est que vous ne pouvez jamais récupérer l'e-mail, même si vous en avez vraiment besoin (par exemple pour contacter vos utilisateurs en cas de compromis, comme suggéré dans les commentaires).
Si vous devez pouvoir récupérer les e-mails, chiffrez-les une fois avec une clé que vous contrôlez. Pas besoin de crypter l'e-mail deux fois à des fins différentes ici - faites-le une seule fois. La partie délicate avec cette solution est où stocker la clé .
Avez-vous vraiment besoin de l'adresse e-mail des utilisateurs?
Si vous stockez l'adresse e-mail sous forme de hachage (e-mail + sel): sel, vous pouvez vérifier trivialement l'adresse e-mail fournie par l'utilisateur. Si l'utilisateur demande une réinitialisation du mot de passe, vérifiez simplement que l'adresse e-mail correspond et envoyez l'e-mail à l'e-mail fourni par l'utilisateur.
Si vous souhaitez autoriser les recherches dans la base de données en fonction de l'adresse e-mail (le nom d'utilisateur étant un e-mail par exemple), ce modèle ne fonctionnera évidemment pas. Cependant, comme indiqué par Conor Mancone , un poivre global pour toutes les adresses fonctionnera, mais réduira quelque peu la sécurité.
Cela vous évite évidemment d'envoyer des newsletters. Mais cela signifie qu'une violation de la base de données ne révélera pas les adresses e-mail.
Une alternative aux réponses existantes: placez les e-mails sur une machine et une application distinctes et stockez uniquement les hachages dans votre base de données d'application principale.
Utilisez le hachage pour vérifier les e-mails.
Lorsque vous devez envoyer un e-mail, votre application communiquera avec cet autre service en transmettant le message de hachage + e-mail et l'autre application enverra l'e-mail.
De toute évidence, un pirate pourrait pirater la machine secondaire et accéder aux e-mails, mais vous ajoutez toujours de la sécurité car:
- La machine secondaire n'a pas besoin d'être exposée à Internet
- La machine secondaire peut être extrêmement minimale, elle n'a qu'à exposer une API très très limitée à votre application et disposer d'un service d'envoi d'emails
- Il peut être verrouillé beaucoup car il ne fait qu'une chose très spécifique
Ainsi, la surface d'attaque de la machine secondaire peut être façon plus petite que celle de votre application.
Points bonus: vous pouvez appliquer les autres réponses à votre machine secondaire, augmentant encore plus la sécurité (même si ce ne sera jamais parfait si vous supposez que vous êtes déjà piraté ...)
La connexion nécessite de rechercher l'adresse e-mail, qui n'est pas évolutive si elle est hachée correctement - avec 10 000 utilisateurs dans votre système, vous devrez hacher le courrier électronique d'un utilisateur en moyenne 5 000 fois à chaque connexion, en raison de sels.
Puis-je remettre en question votre prémisse?
"J'ai pensé que l'utilisateur avait besoin de l'email pour se connecter évidemment"
Pourquoi ne pas leur attribuer (ou les laisser sélectionner) un nom d'utilisateur à la place? Cela ne sera pas lié à leur e-mail, sauf s'ils choisissent un nom d'utilisateur très proche de leur e-mail.
De toute évidence, vous avez toujours besoin de leur e-mail si vous effectuez une réinitialisation du mot de passe, mais vous ne pouvez pas l'offrir, utiliser une méthode alternative (par exemple, un code OTP donné lors de l'inscription), ou conserver une base de données distincte de noms d'utilisateurs pour les e-mails.