【发布时间】：2012-06-10 18:40:18
【问题描述】：
在某些情况下，不允许组织使用或存储有用的密钥，例如 SSN 号码、电话号码等。
但是，这些唯一键对于匹配数据非常有用。因此，理论上，如果数据提供者能够为您提供 SSN 的散列值，并且您要存储该散列并使用它进行匹配，那么您将永远不必使用或存储 SSN。
对于像 SSN 这样的东西，什么是合适的散列函数？
【问题讨论】：
标签： .net security hash numbers
【发布时间】：2012-06-10 18:40:18
【问题描述】：
您需要像对待密码一样对待 SSN。使用强而慢的散列算法（例如 bcrypt 或 PBKDF2）对它们进行散列，并使用唯一的每条记录前缀和后缀盐。
散列 SSN 的缺点是它们是可预测的，并且熵非常少，这使得明文暴力破解非常容易。如果您负担得起，我建议您为此类事情投资硬件保护（即HSM）。事实上，你应该完全avoid identifying people by their SSN。
【讨论】：
-
@HunterMcMillen 填充的位数不必具体，只要在数据前后有大量填充即可。
-
通常散列函数处理 n 位块中的数据，如果传入的数据
-
@HunterMcMillen 当然可以，但对于所有实际攻击来说，盐只是为了防止相同明文之间的冲突并阻止彩虹表生效。
-
由于 SSN 的独特性质，这里的盐似乎无关紧要。如果您要添加盐值来填充 SSN，您不妨只生成一些其他唯一 ID。
-
@chris 那么我认为最好的选择是永远不要存储 SSN，并为用户提供不同形式的唯一 ID。
因此，理论上，如果数据提供者能够为您提供 SSN 的哈希值，并且您要存储该哈希值并使用它进行匹配，那么您将永远不必使用或存储 SSN。
这是错误的；设计的哈希不是唯一的，不能用于唯一标识任何东西。如果您必须唯一标识某物，并且不允许使用其他人的标识符，则您必须提出自己的标识符。这就是为什么诸如加油卡、电影租赁卡等之类的东西。带有他们自己的唯一成员身份标识符。
【讨论】：
-
如果提供者对一个数字进行哈希处理，而我用相同的算法对相同的数字进行哈希处理，则哈希值将是相同的。然后我可以将我的哈希数据与他们的数据进行匹配，他们的数据是相同的哈希值。
-
@Chris，如果提供者对两个不同的数字进行哈希处理，它们可以得出相同的哈希值。您会将两个不同的 SSN 视为同一个。
-
我相信一个好的散列算法的重点是减少或消除冲突的可能性，即使对于小输入也是如此。看看stackoverflow.com/questions/4676828/…