通过社会安全号码安全存储和搜索

Question

因此,我正在研究人力资源部门所需的基于网络的补充系统,以存储和搜索前人员的记录.我满足了这个要求,但最终传下来的是系统必须能够通过完整的SSN进行搜索,并检索完整的SSN.除了我的抗议之外,采取一些措施保护这些数据实际上将是他们现在正在做的事情的巨大改进(你不想知道).

我一直在做很多研究,我认为我已经提出了一个合理的计划 - 但是就像所有加密/安全相关的东西都有很多复杂性,并且很容易犯错误.我的粗略计划如下:

1. 在第一次运行应用程序时,使用RijndaelManaged生成大型随机盐和128位AES密钥
2. 将这两个写入明文文件以进行紧急恢复.该文件将在离线存储在安全的物理位置.应用程序将检查文件是否存在,如果它仍然在那里,则尖叫警告.
3. 将盐和密钥存放在某处.这是我没有很好答案的部分.我打算使用DPAPI - 但我不知道它在一天结束时到底有多安全.将它留在明文并限制文件系统访问其存储的目录,我会更好吗？
4. 将记录写入数据库时​​,将SSN与上面的大盐值一起散列,以生成可搜索的字段(但不能在不获取盐和暴力的情况下恢复所有可能的SSN),并且AES使用以下方法加密原始SSN值.新的IV(存储在旁边)生成可检索的字段(使用密钥/ iv)但不可搜索(因为加密相同的SSN两次应产生不同的输出).
5. 搜索时,只需使用相同的哈希值搜索值,然后在数据库中查找
6. 检索时,使用AES密钥/ iv解密数据库中的值

除了需要以相对安全的方式存储密钥(上面的数字3)之外,它似乎足够坚固.

对我们不起作用的事情:

• "不要做任何这个"不是一种选择.这需要做,如果我们不这样做,他们会a)对我们生气,b)只是通过电子邮件传递明文档中的所有数字.

这只是我们网络的内部,所以我们至少在这里实现的任何内容上都有这层保护.对应用程序本身的访问将由活动目录控制.

感谢您阅读,以及任何建议.

更新#1:我从评论中意识到为SSN检索字段保留私有IV是没有意义的.我更新了计划,为每条记录正确生成新IV,并将其与加密值一起存储.

更新#2:我正在删除我不能做的事情列表中的硬件内容.我做了一些研究,看起来这些东西比我想象的更容易接近.使用其中一个USB安全令牌的东西是否为密钥存储增加了有意义的安全性？

Answer 1

我最近不得不解决类似的问题，并决定使用 HMAC 进行哈希处理。这将比简单的哈希提供更多的安全性，特别是当您无法对值加盐时（否则它将无法搜索）。

然后，正如您所说，使用带有随机盐的 AES 进行可逆加密。

也许您不需要加密这些数据，但我别无选择，这似乎是一个合理的解决方案。

我关于 IT 安全的问题https://security.stackexchange.com/questions/39017/least-insecure-way-to-encrypt-a-field-in-the-database-so-that-it-can-still-be -在