我正在建立一个网站，并试图找出一种加密用户电子邮件地址的方法。如果我的数据库被盗，我的用户的电子邮件不是纯文本格式，那就太好了。我认为用户显然需要电子邮件才能登录，所以如果我用他们的密码作为密钥加密它，甚至是电子邮件本身，那么我仍然可以构建一个登录功能，这样就可以了。
当我需要用户的电子邮件地址时，问题就出现了。例如，在密码重置或发送时事通讯的情况下。我可以在数据库中有第二个字段，其中包含用户的电子邮件地址，用我知道的密钥加密。
我可以加密一些东西，两个密钥可以工作吗？像万能钥匙……还是我很愚蠢？
如果您只需要在用户提供电子邮件时验证电子邮件，然后像vidarlo 建议的那样对其进行哈希处理，就像您对密码进行哈希处理一样。这里不需要加密。这种方法的另一面是您永远无法恢复电子邮件，即使您确实需要它（例如，如评论中所建议的那样，在出现妥协的情况下联系您的用户）。
如果您需要能够检索电子邮件，请使用您控制的密钥对它们进行一次加密。此处无需出于不同目的对电子邮件进行两次加密 - 只需执行一次。此解决方案的棘手部分是存储密钥的位置。
你真的需要用户的电子邮件地址吗？
如果您将电子邮件地址存储为 hash(e-mail + salt):salt，您可以轻松验证用户提供的电子邮件地址。如果用户请求重置密码，只需验证电子邮件地址是否匹配，然后将电子邮件发送到用户提供的电子邮件。
如果您想允许基于电子邮件地址（例如用户名是电子邮件）在数据库中查找，则此模型显然行不通。然而，正如Conor Mancone所指出的，所有地址的全局辣椒都可以，但会在一定程度上降低安全性。
显然，这消除了您发送时事通讯的可能性。但这意味着数据库泄露不会泄露电子邮件地址。
现有答案的替代方案：将电子邮件放在单独的机器和应用程序上，并仅将哈希值存储在您的主应用程序数据库中。
使用哈希来验证电子邮件。
当您需要发送电子邮件时，您的应用程序将与传递哈希 + 电子邮件消息的其他服务进行通信，并且其他应用程序将发送电子邮件。
显然，黑客可以入侵辅助计算机并获得对电子邮件的访问权限，但您仍在增加安全性，因为：
因此，辅助机器的攻击面可能比您的应用程序的攻击面小得多。
奖励积分：您可以将其他答案应用于您的辅助机器，从而进一步提高安全性（尽管如果您假设您已经被黑客入侵，它永远不会完美......）
登录需要查找电子邮件地址，如果它们被正确散列，则无法扩展 - 在您的系统中有 10k 个用户，由于盐的原因，您每次登录时必须平均对用户的电子邮件进行 5k 次散列。
我可以质疑你的前提吗？
“我认为用户显然需要电子邮件才能登录”
为什么不给他们（或让他们选择）一个用户名呢？除非他们选择的用户名与他们的电子邮件非常接近，否则这不会与他们的电子邮件相关联。
显然，如果您正在重置密码，您仍然需要他们的电子邮件，但您无法提供此功能，使用替代方法（例如注册时提供的 OTP 代码），或为电子邮件保留单独的用户名数据库。