出于安全考虑，是否值得在将用户电子邮件放入数据库之前对其进行加密？
我知道我们会对密码进行哈希和盐处理，但这是另一个故事，因为我们实际上不需要密码原文。但电子邮件则不同。
考虑到解密密钥仍然会在数据库附近某个地方，那么加密电子邮件是否有意义？我想，如果有人进入系统，他们也会找到密钥，即使不能立即找到，最终也可能找到。
有什么最佳实践吗？如果我运行自己的服务器而不是共享/虚拟主机，是否还有其他选项可用？
编辑：我打算使用SQL Server。并且，这不是具有安全要求的企业软件，只是我心中的一些娱乐网站。
如果您将来需要使用电子邮件地址，则必须以明文形式存储它们。
当然，您可以对其进行加密，但在这种情况下，这实际上是通过“安全性非显而易见性”来保护安全性。基本上，如果您的应用程序外围边界很安全，您的数据可以是明文的。在此加密会增加您处理数据的复杂度，但并不能真正阻止攻击者获取您的原始数据。
正如您所说，如果他穿过了您的外围防线，他很可能轻易地获得解密电子邮件数据的解密密钥。加密可能稍微减慢坚决攻击者的速度，但不会为您的数据添加任何真正的安全性。
最好的方案是对电子邮件地址进行哈希（记得使用盐！）并将其存储。这样，您就可以检查电子邮件地址是否与输入值相同（例如），并验证电子邮件地址输入是否与您存储的相同。当然，这种方法的主要缺点是，如果您想要定期向用户发送电子邮件之类的事情，您就无法知道电子邮件地址是什么。
我猜您正在存储电子邮件地址，因为它是有用的数据，而且您会想要做一些事情（例如发送电子邮件：) ），在这种情况下，加密只会增加处理该数据时的开销，同时几乎没有任何回报。
在这种情况下，我建议将重点放在保护数据库本身的访问上（即您的“外围”防御），确保它们尽可能强而有力，同时将数据保留为明文存储在数据库中。
手机验证很简单。使用类似twilio.com的服务向他们发送短信，并要求他们回复确认码。现在我们知道该手机属于想要注册的客户。使用OpenID，您可以验证其他受信任站点上的现有帐户，确认过程由它们处理。
对于客户进行身份验证，他们只需要提供其手机号码和密码或OpenID身份验证令牌即可。两者都不需要电子邮件地址（虽然OpenID提供者可能需要，但这不是您的责任）。
如果这些选项不可用，则仍然可以确认电子邮件地址，然后将其用于身份验证。确认仅需要存储唯一令牌并向电子邮件地址发送链接。存储电子邮件地址的加盐哈希值，并像处理密码一样使用它来匹配帐户。
交易和营销电子邮件
我们想要存储电子邮件地址的真正原因是为了向他们发送我们认为他们需要的东西的优惠，以便他们可以在不阅读它的情况下将其删除。但说真的，电子邮件是最好的媒介吗？如果我们拥有一个OpenID账户，为什么不用它来进行通知呢？发送Facebook消息或在他们的墙上写字，在Twitter上@提到他们，发送短信到他们的手机，构建应用程序并向他们推送通知。有许多比电子邮件更有效的渠道。这取决于您访问地址的频率。如果您偶尔读取它们，那么这可能是有意义的，但这将是我花时间解决的最后一个安全问题之一。
我不加密用户的电子邮件。重点是保护数据库；如果您实际上想要使用存储的电子邮件，密钥仍然是可访问的。
但请检查地址的有效性和可能的SQL注入。
加密数据库内容始终是一个棘手的考虑。显然，除非可以解密内容，否则内容是无用的，如果必须在没有人为干预的情况下进行解密，则需要在某个地方存储密文和密钥。如果这个“某个地方”在同一台机器上，那么人们可能会想知道你为什么要这样做。
好吧，有几个原因可能会促使你这样做。其中一个原因是因为由于某些公司政策的要求而必须这样做。另一个原因是，也许你的数据库所在的环境比访问它的机器更具敌意。
总的来说，加密数据库内容不会赢得任何奖项，但如果你能够证明其必要性，那么你显然至少有一些动力这样做。
如果您将其与盐一起哈希处理，可能对用户有所帮助。以前我曾经使用过这样的代码，我使用盐和哈希，然后可以解密它。流程是一旦用户注册，就进行哈希和盐（加密过程）。然后，如果需要获取加密数据，就会进行解密。
