When I was working on my user management system, I thought about how to store the email addresses in the database. I wanted as much security as possible while maintaining a functional app. Because email addresses need to be accessible to send emails, they cannot be strongly encrypted with a password derived key. However, while it would certainly be bad to lose emails, they aren’t quite as bad as credit cards or social security numbers. Therefore, you may be able to get away with storing them in cleartext or using obfuscation. You should always focus on making sure that your server cannot be hacked, but if your database gets compromised, it would be nice to have an extra layer of security.

在使用用户管理系统时，我想到了如何在数据库中存储电子邮件地址。 我希望在维护功能正常的应用程序时尽可能获得更高的安全性。 因为发送电子邮件需要访问电子邮件地址，所以不能使用密码派生**对电子邮件地址进行严格加密。 但是，虽然丢失电子邮件肯定很糟糕，但它们却不如信用卡或社会保险号那么糟糕。 因此，您可能可以将它们以明文形式存储或使用混淆处理。 您应该始终专注于确保服务器不会被黑客入侵，但是，如果您的数据库遭到入侵，那么拥有额外的安全层将是一件好事。

为什么要加密电子邮件地址？ (Why encrypt email addresses?)

With data security becoming more of a concern lately, you want to make sure to store user data securely. First of all, you should focus on preventing any database leaks in general, but in the unfortunate case that it is compromised anyway, it would be nice to have additional protection. And on that note, you should strongly consider what data you need to store. After all, the best protection against losing data is not saving it in the first place.

近年来，随着数据安全性越来越受到关注，您需要确保安全地存储用户数据。 首先，通常应该着重于防止任何数据库泄漏，但是在不幸的情况下，无论如何它都会受到损害，最好有附加的保护。 并请注意，您应该强烈考虑需要存储哪些数据。 毕竟，防止丢失数据的最佳保护措施并不是一开始就将其保存。

There are three categories of data: passwords, user data, and user data, that needs to be known by the app. Passwords can be stored as hash values because they are only used for authorization and with a modern hashing algorithm and salt they are going to be fine. User data, that is only accessed by the user himself, can be stored strongly encrypted with a key derived from the password when the user logs in. This means the key to decrypt the private user data is never stored on the server, and therefore that data is also fine.

应用程序需要知道三类数据：密码，用户数据和用户数据。 密码可以存储为哈希值，因为它们仅用于授权，并且使用现代的哈希算法和盐，它们会很好。 只能由用户自己访问的用户数据可以在用户登录时使用从密码派生的**进行高度加密存储。这意味着解密私有用户数据的**永远不会存储在服务器上，因此，数据也很好。

Emails, however, are a special case. They are somewhat sensitive information. Not quite as sensitive as credit cards or social security numbers, but you would prefer to keep your email address private and not receive a ton of spam. But in most applications, you want to be able to send emails to your users, so you cannot encrypt the email addresses with the user password, because then the app wouldn’t be able to decrypt them to send emails. This means you have to find a compromise between security and app functionality. Let’s look at the different methods of storing an email address in your database:

电子邮件是一种特殊情况。 它们是一些敏感信息。 它不像信用卡或社会保险号那样敏感，但是您希望保留电子邮件地址的私密性，并且不会收到大量垃圾邮件。 但是在大多数应用程序中，您希望能够向用户发送电子邮件，因此您无法使用用户密码来加密电子邮件地址，因为那样一来，该应用程序将无法解密它们以发送电子邮件。 这意味着您必须在安全性和应用功能之间找到折衷方案。 让我们看一下在数据库中存储电子邮件地址的不同方法：

明文 (Cleartext)

By far the easiest and most convenient method to store any data is cleartext. It’s easy to understand, makes the database easy to maintain, doesn’t require any additional code, and is therefore very efficient. However, if the database is compromised the attacker has immediate access to all of the information. I believe a lot of companies store emails in cleartext and I have done it in the past as well. If the server and the database are well secured, storing emails this way isn’t a big problem.

到目前为止，最简单，最方便的存储任何数据的方法是明文。 它易于理解，使数据库易于维护，不需要任何其他代码，因此非常高效。 但是，如果数据库遭到破坏，攻击者可以立即访问所有信息。 我相信许多公司都以明文形式存储电子邮件，并且我过去也这样做过。 如果服务器和数据库的安全性良好，则以这种方式存储电子邮件不是大问题。

加密的 (Encrypted)

From a privacy and data security point of view, storing an email address encrypted is the best solution. However, as mentioned, you cannot encrypt the email with a strong key derived from a user's password because that would prevent you from decrypting it to send emails. This means you can only encrypt them with a key that is stored on the server. Storing a key on the server is less secure, but if an attacker has access to the server and is able to read that key, you probably have bigger problems than just decrypted emails. If only the content of the database is compromised though, the emails will be safe.

从隐私和数据安全的角度来看，存储加密的电子邮件地址是最好的解决方案。 但是，如上所述，您不能使用从用户密码派生的强**对电子邮件进行加密，因为这会阻止您解密它以发送电子邮件。 这意味着您只能使用服务器上存储的**对它们进行加密。 在服务器上存储**的安全性较差，但是，如果攻击者可以访问服务器并能够读取该**，则可能会遇到比仅解密电子邮件更大的问题。 如果只破坏数据库的内容，则电子邮件将是安全的。

This was the method I tried for my updated user management system at first. However, as I continued to work on it, I realized that it had some practical flaws. The addresses were encrypted and it was possible to decrypt them to send emails. But there was no easy way to identify a user by his email address, which is needed for a password reset functionality. Strong encryption algorithms use initialization vectors (IVs), which are generated randomly every time something is encrypted. So when a user entered his email to request a password reset link, I couldn’t just encrypt the email again to compare against all encrypted emails in the database, because the second encryption would have a different IV. In theory, you could decrypt all emails in the database to compare against the entered one, but imagine you have thousands of users (or even more), decrypting that many emails for a single comparison would be extremely slow.

这是我最初为更新的用户管理系统尝试的方法。 但是，当我继续研究时，我意识到它存在一些实际缺陷。 地址已加密，可以解密以发送电子邮件。 但是，没有简单的方法可以通过用户的电子邮件地址来识别用户，这是密码重置功能所必需的。 强大的加密算法使用初始化向量(IV)，该向量在每次加密时都会随机生成。 因此，当用户输入电子邮件以请求密码重置链接时，我不能仅对电子邮件进行再次加密以与数据库中的所有加密电子邮件进行比较，因为第二种加密将具有不同的IV。 从理论上讲，您可以解密数据库中的所有电子邮件以与输入的电子邮件进行比较，但是假设您有成千上万的用户(甚至更多)，那么一次比较就解密那么多电子邮件将非常慢。

Therefore, you need a relationship between the plaintext and the IV. Depending on the encryption algorithm, using a predictable IV is very bad and significantly weakens the encryption strength. They are probably still reasonably secure, but even if they aren’t, at the very least they look encrypted and maybe deter an attacker from trying to break the encryption.

因此，您需要在纯文本和IV之间建立关系。 根据加密算法的不同，使用可预测的IV会非常糟糕，并且会大大削弱加密强度。 它们可能仍然是相当安全的，但是即使不是，它们也至少看起来像是加密的，并且可能阻止攻击者尝试破坏加密。

混淆 (Obfuscation)

Making the email address only look encrypted is known as obfuscation. When a hacker gets the content of your database and the email addresses look like they are encrypted, he may not even try to decrypt them. Especially when you don’t have a lot of emails, the effort of trying to break the encryption may not be worth the time.

使电子邮件地址看起来只有加密状态被称为混淆。 当黑客获取您数据库的内容并且电子邮件地址看起来像已加密时，他甚至可能不会尝试对其解密。 尤其是当您没有很多电子邮件时，尝试破坏加密的工作可能不值得花时间。

I don’t know whether real encryption with a predictable IV is technically still called encryption, but it is certainly really strong obfuscation. I ended up creating my own obfuscation function because it is faster than using a real encryption algorithm, that may not actually be that strong without a random IV. Considering the lower sensitivity of email addresses compared to credit cards or the like, obfuscation may be a good compromise between security and functionality.

我不知道具有可预测IV的真实加密在技术上是否仍被称为加密，但这无疑是一种很强的混淆。 我最终创建了自己的混淆函数，因为它比使用真正的加密算法要快，如果没有随机IV，它实际上可能没有那么强。 考虑到与信用卡等相比，电子邮件地址的敏感性较低，因此混淆可能是安全性和功能之间的良好折衷。

昏迷 (Hashed)

It is also possible to store email addresses as hash values in the database. By storing them hashed you lose the ability to send emails because there is no way to calculate the original text from the hash value. However, if you only need the email address as part of the login process to authorize a user, storing a hash value is a good solution.

也可以将电子邮件地址作为哈希值存储在数据库中。 通过散列存储它们，您将失去发送电子邮件的功能，因为无法根据散列值计算原始文本。 但是，如果在登录过程中仅需要电子邮件地址来授权用户，则存储哈希值是一个很好的解决方案。

Whenever you need to store email addresses in a database there is a trade-off between security and functionality. You would like to provide the most secure app to your users while maintaining usability. Because email addresses need to be accessible by your app to send spam, ehm, I mean very important information, of course, you cannot use strong encryption to store them in the database. Instead, you are most likely going to use some form of obfuscation to make the emails seem encrypted and deter attackers from cracking them. You should do whatever you can to secure your server and your database, but if they do get compromised, it’s good to have that extra layer of security.

每当您需要将电子邮件地址存储在数据库中时，都需要在安全性和功能之间进行权衡。 您希望在保持可用性的同时为用户提供最安全的应用程序。 因为您的应用需要访问电子邮件地址才能发送垃圾邮件，所以，我的意思是非常重要的信息，当然，您不能使用强加密来将它们存储在数据库中。 取而代之的是，您很可能会使用某种形式的混淆处理，以使电子邮件看起来像是加密的，并阻止攻击者**它们。 您应该尽一切努力保护服务器和数据库的安全，但是如果确实遭到破坏，那么最好拥有额外的安全层。