加密电子邮件、哈希密码并将其存储在数据库中？
首先，我对加密和散列的理解：
- 加密 - 可以解密
- 散列 - 无法取消散列
在构建 Web 应用程序时，我应该：
- 使用加密密钥加密电子邮件地址（将用于登录）。很高兴能够解密电子邮件地址以供以后使用（例如向用户发送电子邮件）
- 。用盐对密码进行哈希处理。没有人应该能够看到用户的密码，因此散列（因为它是单向的）是很好的。
如果上述两点是正确的，我应该在哪里存储加密密钥和盐？
如果我将其存储在数据库中，那么如果数据库受到损害，这似乎有点毫无意义。不过，好处是我可以为每个用户分配唯一的加密密钥和盐。
我应该将加密密钥和盐存储在应用程序的配置中吗？如果数据库被泄露，至少加密密钥和盐不会被泄露（希望如此）。问题在于，这可能意味着每个人都共享相同的加密密钥和盐。
关于做什么的建议？
First off, my understanding of encrypting and hashing:
- Encrypting - can be decrypted
- Hashing - can NOT be unhashed
When building a web application, I should:
- Encrypt the email address (will be used to login) with encryption key. It's nice to be able to decrypt email addresses for later use (e.g. emailing users)
- Hash the password with a salt. No one should be able to see user's password, so hashing (since it is one-way) is good.
If the above 2 points are right, where should I store the encryption key and salt?
If I store it in the DB, the seems a bit pointless should the DB ever be compromised. The benefit, though, is that I can assign a unique encryption key and salt for each user.
Should I store the encryption key and salt in my application's configuration? If the DB is ever compromised, at least the encryption key and salt are not also compromised (hopefully). The problem with this is that it probably means that everyone shares the same encryption key and salt.
Suggestions on what to do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您对电子邮件进行加密，则需要使用普通的盐/密钥来进行加密。否则，您如何通过数据库中的电子邮件地址选择用户来检查哈希密码是否正确？您无法每次都解密每个电子邮件地址。
总的来说，我认为加密电子邮件地址几乎没有什么好处。如果需要，可以使用 MySQL 数据库加密，但不必在应用程序级别担心这一点。
用于散列密码的盐应该/需要是唯一的并且可以存储在数据库中，事实上它可以是散列本身的一部分。请参阅 http://www.openwall.com/phpass/ 了解良好的实施方式。
If you encrypt the email at all, you need to do it with a common salt/key. Otherwise, how are you going to select a user by his email address from the db to check whether the hashed password is correct? You can't decrypt every email address every time.
Overall, I think there's very little to be gained from encrypting email addresses. Use MySQL database encryption if you want, but don't worry about this at the application level.
The salt for hashing the password should/needs to be unique and can be stored in the database, in fact it can be part of the hash itself. See http://www.openwall.com/phpass/ for a good implementation.
你的理解对我来说似乎是正确的。
密码：仅应存储密码的哈希值以及用户特定的盐。 salt可以存储明文，salt的原因是，攻击者不能为所有用户使用一个彩虹表（构建一个彩虹表是昂贵的）。推荐使用
hash_hmac()函数。电子邮件：我认为对这些地址进行加密是一个好主意，但是无论你怎么做，如果攻击者控制了服务器，他将能够恢复这些地址。我会将密钥放在一个单独的目录中，该目录位于网络根目录之外（无法直接从网络访问）。不要将其写在无需解释即可交付的文件中，扩展名 *.php 比 *.inc 更好。如果您无权访问这样的目录，至少创建一个目录并使用 .htaccess
Deny from all对其进行保护。如果您需要在数据库中查找电子邮件地址，您可以另外存储哈希值，这允许搜索不区分大小写（首先转为小写，然后生成哈希值）。
Your understanding seems correct to me.
Password: Only the hash of a password should be stored, together with a user specific salt. The salt can be stored plaintext, the reason for the salt is, that an attacker cannot use one single rainbowtable for all users (building a rainbowtable is expensive). It's recommended to use the
hash_hmac()function.EMail: I think it's a good idea to encrypt these adresses, but however you do it, if the attacker has control over the server, he will be able to recover these addresses. I would put a secret key in a separate directory, which is outside the web root (cannot be accessed directly from the web). Don't write it in a file that can be delivered without interpreting, the extension *.php is better than *.inc . If you have no access to such a directory, at least make one and protect it with .htaccess
Deny from all.If you need to find an email address in the DB you can additionally store a hash, this allows to search case insensitive (first turn to lowercase, then generate the hash).
salt 应该是针对每个用户的，并且确实可以在数据库中；因此，盐的意义在于，拥有数据库副本的人无法一次破解所有密码，而是单独破解每个密码。
至于加密密钥，这是一个更难的问题 - 绝对不要将其存储在数据库中；如果您的平台提供任何类型的受保护存储，您可能需要使用它。例如，请参阅此以获得有用的答案：什么是最好的在 MySQL 中使用/存储加密密钥的方法
The salt should be per-user, and can be indeed in the database; thus the point of a salt is that someone with a copy of your db can't work on cracking all the passwords at once, but each separately.
As for the encryption key, that's a much harder issue - definitely don't store it in the database; if your platform offers any kind of protected storage, you may want to use that. See e.g. this for useful answers: What's the best method to use / store encryption keys in MySQL