通过社会保险号安全地存储和搜索 [英] Securely storing and searching by social security number

问题描述

因此，我正在开发人力资源部门所需的基于Web的补充系统，以存储和搜索前人员的记录.我满足了要求，但最终被告之，该系统必须既支持通过完整SSN进行搜索，又可以实现对完整SSN的检索.除了我的抗议之外，采取一些步骤来保护这些数据实际上将比他们现在正做的事情(您不知道)大有改进.

So I'm working on a supplemental web-based system required by an HR department to store and search records of former personnel. I fought the requirement, but in the end it was handed down that the system has to both enable searching by full SSN, and retrieval of full SSN. My protestations aside, taking some steps to protect this data will actually be a huge improvement over what they are doing with it right now (you don't want to know).

我一直在做很多研究，我想我想出了一个合理的计划-但是像所有与加密/安全性相关的事情一样，它的复杂性非常高，而且很容易犯错.我的粗略计划如下:

I have been doing a lot of research, and I think I have come up with a reasonable plan -- but like all things crypto/security related there's an awful lot of complexity, and it's very easy to make a mistake. My rough plan is as follows:

1. 在首次运行该应用程序时，使用RijndaelManaged生成大量随机盐和一个128位AES密钥
2. 将这两者都写入纯文本文件以进行紧急恢复.该文件将离线存储在安全的物理位置.该应用程序将检查文件是否存在，并在文件仍坐在那里时发出警告.
3. 将盐和钥匙安全地存放在某个地方.这是我没有很好答案的部分.我当时计划使用DPAPI，但是我不知道它到底到底有多安全.仅将其保留为纯文本格式，并限制文件系统对其所存储目录的访问，我会更好吗?
4. 将记录写到数据库时，对SSN和上面的大盐值进行哈希处理，以生成可搜索的字段(但如果不获取盐和强行强制所有可能的SSN，则不可恢复)，并且AES加密原始SSN值(带有新的IV)(存储在旁边)以生成可检索(使用键/iv)但不可搜索的字段(因为两次加密同一SSN会产生不同的输出).
5. 搜索时，只需用相同的盐对搜索值进行哈希处理，然后在数据库中查找
6. 检索时，使用AES密钥/iv从数据库解密值

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

Other than needing a way to store the keys in a relatively secure way (number 3 above) it seems solid enough.

不适用于我们的东西

• 请勿执行任何此操作"不是一种选择.这是必须要做的，如果我们不这样做，他们会a)对我们生气，b)只是通过电子邮件将所有数字传递到纯文本文档中.

这仅是我们网络的内部内容，因此我们至少在此处实现的任何内容之上都具有该保护层.对应用程序本身的访问将由活动目录控制.

This will be internal to our network only, so we have that layer of protection at least on top of whatever is implemented here. And access to the application itself will be controlled by active directory.

感谢您的阅读和任何建议.

Thank you for reading, and for any advice.

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

Update #1: I realized from the comments that it makes no sense to keep a private IV for the SSN retrieval field. I updated the plan to properly generate a new IV for each record and store it alongside the encrypted value.

更新#2:我将从我们无法做的事情清单中删除硬件.我做了一些研究，似乎这些东西比我想象的要容易得多.使用这些USB安全令牌中的一种可以为密钥存储添加有意义的安全性吗?

Update #2: I'm removing the hardware stuff from my list of stuff we can't do. I did a bit of research, and it seems like that stuff is more accessible than I thought. Does making use of one of those USB security token things add meaningful security for key storage?

推荐答案

最近我不得不解决一个类似的问题，因此决定使用HMAC进行哈希处理.这将比简单的哈希提供更多的安全性，尤其是因为您无法对值加盐(否则将无法搜索).

I've had to solve a similar problem recently and have decided to use an HMAC for the hashing. This would provide more security than a simple hash, especially as you can't salt the value (otherwise it wouldn't be searchable).

然后，正如您所说的，将AES和随机盐一起用于可逆加密.

Then as you say, use AES with a random salt for the reversible encryption.

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

It maybe that you don't need to encrypt this data but I had no choice and this seemed like a reasonable solution.

我对IT安全性的问题

My question on IT Security https://security.stackexchange.com/questions/39017/least-insecure-way-to-encrypt-a-field-in-the-database-so-that-it-can-still-be-in

这篇关于通过社会保险号安全地存储和搜索的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！