我遇到類似如下的問題：替代散列SSN作爲MySQL中的密鑰
某人開始擔任「A公司」的顧問。他們的人力資源人員爲他們設立了一個賬戶。爲「人」表和「人 - 公司」中的人員創建記錄。
此人也在爲「公司B」（公司A可能或可能不知道）工作。當公司B輸入他們的信息時，他們不應該在「人員」中創建記錄，而應該在「人員公司」中創建一個記錄。
的人須爲國家做培訓，所以如果他們登錄到任何一家公司的網站時，他們做培訓，我們希望總時間保持與人。
我可以爲人員表設置一個PK表，將他們加入到每個公司，但我認爲我需要像人員SSN的散列，並附加一些額外的「xyz」以便能夠進行查找。 B公司將擁有該人的SSN，這應該是普遍的。
問題：
1）是否有一些其他的方法來加入你們當中一個認爲會更好地工作？
2）如果我做一個哈希SSN辦法去，什麼是使用的MySQL/PHP的單向加密最好的加密？
我看別的地方，一個公鑰/私鑰的解決方案可能是最好的，但因爲人沒有建立自己的帳戶最初我不知道如何做到這一點的工作。
感謝
我認爲this article可能與您正在做的事情非常相關。如果出於安全原因和法律責任確實希望「匿名化」SSNs，那麼僅對它們進行散列是不夠的。
只是散列他們將是一個完全確定的過程，所以要有效地「屏蔽」個人核潛艇，該過程需要是隨機的。否則，你可以簡單地通過所有可能的SSN組合（這將比試圖強制散列函數所需的工作少得多）並且尋找匹配值。
要明白爲什麼這持有了一個最簡單的例子，一個SSN可能只取兩個值0和1.不管哈希函數的質量和強度如何，最終只會有兩個可能的結果，很容易看出哪個是哪個。
這是你爲什麼不應該散列的舊遊戲。密碼直接不需要對它們進行一些預處理。底層數據不包含足夠的熵，因此將成爲預計算表中查找的簡單目標。
當你的SSN成爲私人和機密的時候（它們不在每個國家，所以請諒解我在評論中的愚蠢問題:)，也用於密碼存儲的相同最佳實踐也適用於您的特定情況，即緩慢的自適應哈希算法，可補償初始熵的不足，如bcrypt，scrypt和PBKDF2（已由Marcus Adams推薦）。
PKI將是你的使用情況過於複雜，並可能增加系統中的安全漏洞的數量。使用散列SSN將會很快且相當便攜 - 我會推薦SHA-2。它事實上推薦作爲Federal Information Processing Standard的一部分。
我堅持只有sha1（）可用的MySQL 5.1。我可以在php中做這個... hash（'sha256'，'xyz123456789abc'）;然後存儲爲字符（96），我相信。那會是相同的嗎？ – Don
我相信VARBINARY或BLOB是推薦用於存儲加密數據的MySQL類型。 SHA-1並沒有真正被打破，所以你***可以使用它。然而，如果安全性是您的首要考慮因素，那麼使用VARBINARY或BLOB在PHP中計算哈希並存儲在MySQL中。 – Perception
*如果您將其存儲爲字符類型，請先將其編碼爲十六進制或base64，並注意您需要將散列的輸出大小加倍爲字符。 –
爲了保證哈希安全，您需要一個隨機鹽以防止彩虹攻擊。但是，隨機鹽會妨礙將其用作查找值的能力。
將哈希與人的姓拼在一起會比沒有好，它仍然允許您執行查找。
PKI算法通常比使用相同的密鑰長度的良好的對稱算法較弱，所以如果你想使用可逆加密算法，你不希望使用PKI。
隨機醃製單向散列算法將是理想的，SHA1和以上應該沒問題，但PBKDF2會更好。
SHA2被支撐在MySQL 5.5+，並且兩個SHA1和SHA2返回一個十六進制編碼的哈希值，所以它可以被存儲在索引固定長度CHAR列。
+1我會預先輸入一個主機名或密碼前面的一個隨機字符串，以防範跨站點使用相同名稱/密碼的用戶。 –
OP沒有存儲密碼，並且由於散列必須可以從不同的主機計算，所以鹽不能是純粹的隨機的。 – Perception
我可能不會完全監督這種情況，但如果您不能使用預先計算好的隨機公開可見的鹽，則這種情況很奇怪。 –
如果SSN已經普及，爲什麼還需要進一步散列呢？你在那裏得到鑰匙，還是有另一個要求？ – emboss
@emboss - 因爲存儲SSN會增加您的法律責任和潛在的安全風險。 – Perception
散列SSN只是作爲一個單向查找來查看是否已經在系統中設置了「人員」，並且只會被查詢......從未選擇或通過。更擔心如果數據庫曾經以某種方式暴露出來，會發生什麼，我沒有想到。 – Don