表单身份验证 - 如何防止欺骗用户帐户只知道扩展的用户信息？
我陷入了一个奇怪的困境。 请耐心等待我尝试解释它！
我正在使用表单身份验证，并将其他用户信息存储在另一个表中（从表单身份验证引用的 UserID、加密的 SSN、Salt 值）。 当用户注册该网站时，我会询问 SSN、DOB 和 LName，并在他们创建帐户之前根据我们的系统进行验证。 我想确定该 SSN 是否在表单身份验证中具有与其关联的帐户。 由于 SSN 是使用盐值加密的，因此如果不查看每一行，我就无法进行查找。
我只需要每个 SSN 1 个用户帐户。 使用盐值会破坏这一点。
在我看来，解决这个问题的唯一方法是对 SSN 使用通用的加密算法。 当用户输入时，我应用相同的加密算法并查看用户扩展属性表中是否存在值匹配。
这足够安全吗？
I'm in a bit of a strange dilema. Please bear with me as I try to explain it!
I'm using forms authentication and am storing additional user information in another table (referenced UserID from Forms Auth, encrypted SSN, Salt value). When users register to the site, I ask SSN, DOB and LName and verify against our system before they create an account. I want to determine if that SSN has an account associated with it in forms authentication. Since the SSN is encrypted with a salt value, I can't do a lookup without looking at each row.
I only want 1 user account per SSN. Using a salt value disrupts this.
The way I see it, the only way around this is to use a common encryption algorithm for the SSN. When the user types it in, I apply the same encrypt algorythm and see if there is a value match in the user extended properties table.
Is this secure enough?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不要使用相同的盐值，而是根据其他用户信息生成盐，以便可以重建它。 因此，一旦用户应用，您就可以重新生成盐，并且可以生成预期的哈希值并在单个查询中完成工作。
Rather than use the same salt value, generate the salt based on the other user information so that it can be reconstructed. Thus, you can regenerate the salt once the user applies, and you can generate the expected hash and get the job done in a single query.
如果您希望加密（而不是散列）SSN 值，那么将密钥存储在 Natso 指出的同一个表中并不是一个好习惯。 这充满了危险，因为密钥不会与它们保护的数据一起存储 - 如果攻击者设法获取数据库的转储，他将能够解密加密的内容，因为密钥是一起存储的。
应用程序应从安全密钥存储中获取密钥，然后使用该密钥来加密/解密信息。 这样，您可以继续在数据库中存储敏感信息，从而保护您的信息，并应用不同的机制（通常是文件系统安全）来保护您的密钥存储。
当然，假设您的要求是以安全的方式将数据存储在数据库中，并在以后的某个时间恢复相同的数据。 但是，如果您不希望数据在通过算法后即可恢复，则应该探索哈希的使用。
If you wish to encrypt (not hash) the SSN value, it is not a good practice to store the key in the same table as Natso has pointed out. This is fraught with danger, since keys are not to be stored with the data they protect - if an attacker manages to obtain a dump of your database, he would be able to decrypt the encrypted contents, since the key is stored along-side.
The application should obtain the key from a secure key store which could then be used to encrypt/decrypt the information. This way, you could continue to store sensitive information in the database thereby protecting your information, and apply a different mechanism (usually file-system security) to protect your key store.
This is of course, assuming that your requirement is to store data in a secure manner in the database, and recover the same at a later point time. However, if you do not the data to be recoverable once it has passed through an algorithm, you should explore the use of hashes.
每次使用相同的盐。 然后您可以比较加密的值。
Use the same salt every time. Then you can compare the encrypted values.