将密码散列与加密的 AES 密钥一起存储的安全隐患
我使用 PKCS#5 标准使用随机且唯一的盐和输入中的用户密码来生成密钥。将此密钥视为“加密”密钥。
“加密”密钥用于加密随机 AES 密钥。每个用户都有一个与其个人资料关联的 AES 密钥。
因此，用户的个人资料将包含以下信息：
-->用于身份验证目的的密码哈希。
--> PKCS#5 算法中使用的盐。 （从 PKCS#5 V2.0 文档中，我们知道该信息不需要保护）。
-->随机生成的加密 AES 密钥，并使用 PKCS#5 算法生成的“加密”密钥以及盐和用户密码进行加密
我问自己，拥有密码的哈希是否有危险，同时使用 salt 和加密的 AES 密钥。我 99.9% 确信这不是问题，但是它是否可以帮助攻击者掌握所有这些详细信息？
I am using the PKCS#5 standard to generate a key using a random and unique salt and the user`s password in input. Consider this key as the "encryption" key.
The "encryption" key is used to encrypt a random AES key. Each users have an AES key associated to their profile.
So, a user`s profile will contains this informations:
--> password hash for authentication purpose.
--> salt used in the PKCS#5 algo. (From the PKCS#5 V2.0 documentation, we know that this information needs no protection).
--> the encrypted AES key generated randomly and encrypted with the "encryption" key generated by the PKCS#5 algo with the salt and the user`s password
I was asking myself if it is dangerous to be in possession of the password`s hash, the salt and the encrypted AES key IN THE SAME TIME. I am 99.9% sure that this is not a problem, but can it facilitates the work of an attacker being in possession of all those details?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
密码哈希还需要使用盐，否则可能会发生字典攻击，并且碰巧选择相同密码的两个用户将在数据库中存储相同的哈希密码。
我建议这样做：只需使用 PKCS#5 两次；一次生成散列密码（您以明文形式存储），一次生成加密密钥（您不存储）。
确保盐很大、随机且独立，这样密码散列和加密密钥之间就不会存在可检测到的关系。毕竟，这就是盐的用途。
[更新，详细说明一下]
选择两种盐 s1 和 s2。确保每个都至少为 64 位、随机且独立。
使用密码 + s1 作为空字符串上 PKCS#5 HMAC 的输入。这是“哈希密码”。
使用密码 + s2 作为 PKCS#5 加密方案的输入来加密实际数据。
将散列密码、s1 和 s2 以明文形式存储在数据库中。完毕。
The password hash also needs to use a salt, otherwise dictionary attacks are possible and two users who happen to pick the same password will have the same hashed password stored in the DB.
I would suggest this: Just use PKCS#5 twice; once to generate the hashed password (which you store in the clear), and once to generate the encryption key (which you do not).
Make sure the salts are large, random, and independent, and then there will be no detectable relationship between the password hash and the encryption key. That is what the salt is for, after all.
[update, to elaborate a bit]
Pick two salts s1 and s2. Make sure each is at least 64 bits, random, and independent.
Use the password + s1 as input to a PKCS#5 HMAC on the empty string. This is the "hashed password".
Use the password + s2 as input to a PKCS#5 encryption scheme to encrypt the actual data.
Store the hashed password, s1, and s2 in the clear in the database. Done.