我有一个类似于以下的问题：
一个人开始担任“A 公司”的顾问。他们的人力资源人员为他们设置了一个帐户。在“person”表和“person-company”表中为该人创建了一条记录。
此人还为“B 公司”工作（A 公司可能知道也可能不知道）。当 B 公司输入他们的信息时，他们不应该在“person”中创建记录，而应该在“person-company”中创建记录。
该人员需要为该州进行培训，因此如果他们在进行培训时登录到任一公司的站点，我们希望总小时数与该人员保持一致。
我可以为将他们加入每个公司的人员表设置一个 PK，但我认为我需要一些类似于人员 SSN 的哈希值以及一些额外的“xyz”以便能够进行查找。B公司将拥有该人的SSN，该SSN应该是通用的。
问题：
1) 有没有其他方法可以加入你们认为效果更好的方法？
2) 如果我确实采用了散列 SSN 方法，那么 MySQL/PHP 用于单向加密的最佳加密是什么？
我在其他地方读到，公钥/私钥解决方案可能是最好的，但由于该人最初没有设置自己的帐户，我不确定这将如何工作。
谢谢
For hashing to be secure, you really need a random salt in order to prevent rainbow attacks. However, a random salt would preclude the ability to use it as a lookup value.
Salting the hash with the person's last name would be better than nothing, and it would still allow you to perform the lookup.
PKI algorithms are generally weaker than a good symmetric algorithm using the same key length, so if you're thinking about using a reversible encryption algorithm, you wouldn't want to use PKI.
A randomly salted one way hashing algorithm would be ideal, and SHA1 and above should be fine, though PBKDF2 would be better.
SHA2 is supported in MySQL 5.5+, and both SHA1 and SHA2 return a hex encoded hash value, so it could be stored in an indexed fixed-length CHAR column.
我认为这篇文章可能与您正在做的事情非常相关。如果您出于安全原因和法律责任确实希望对 SSN 进行“匿名化”，那么仅对它们进行散列是不够的。
只是散列它们将是一个完全确定的过程，因此为了有效地“屏蔽”单个 SSN，该过程需要随机化。否则，您可以简单地通过所有可能的 SSN 组合进行暴力破解（这比尝试暴力破解哈希函数所需的工作要少得多）并寻找匹配的值。
看看为什么会这样，举一个最简单的例子，一个 SSN 可以只取两个值，0 和 1。不管散列函数的质量和强度如何，最终只会有两种可能的结果，很容易看出哪个是哪个。
这是为什么你不应该直接散列例如密码而不首先对其进行一些预处理的老游戏。基础数据只是不包含足够的熵，因此将成为在预先计算的表中查找的简单目标。
您的 SSN 变得私密和机密的那一刻（它们不在每个国家/地区，所以请原谅我在评论中提出的愚蠢问题 :)，同样用于密码存储的最佳实践也应该适用于您的特定情况，即缓慢自适应散列算法，可弥补初始熵的不足，例如 bcrypt、scrypt 和 PBKDF2（Marcus Adams 已经推荐过）。
PKI 对于您的用例来说过于复杂，并且可能会增加系统中安全漏洞的数量。使用散列的 SSN 将是快速且相当便携的 - 我会推荐 SHA-2。事实上，它被推荐为联邦信息处理标准的一部分。