加密數據庫中的登錄ID
我正在開發一個解決方案，其中每個使用者都使用社會安全號碼 (SSN) 進行辨識。所以他們使用他們的 SSN 和密碼登錄。
我想在將 SSN 發送到後端之前以某種方式（客戶端）對其進行加密，以便任何有權訪問後端和數據庫的人都無法知道 SSN 是什麼。
所以，我想一個天真的方法是在發送之前對 SSN 進行雜湊處理，後端可以找到匹配的行。
為所有可能的 SSN 創建一個彩虹表並不是什麼大挑戰，我想整個事情可能會在幾天內被破解，如果不是更少的話。
使用對稱或非對稱加密會產生相同的缺陷，因為攻擊者可以很容易地知道必須傳輸給客戶端的密碼或公鑰。
這類問題有什麼聰明的解決辦法嗎？我猜無論客戶端向伺服器發送什麼，它都必須有一個隨機組件。那麼伺服器如何查找呢？
我想說不要出於實際和道德原因使用 SSN 之類的使用者名。然而，我希望如果您切換到普通使用者名/密碼，您不會刪除您已經擁有的加密 SSN 上的（弱）密碼保護。可能還有圍繞 SSN 儲存的法律要求，但我對此一無所知。絕對不要使用 SSN，因為您相信對使用者施加一些“實名”理念。如果您正在為某人填寫表格，那麼請考慮僅儲存 SSN 客戶端，即使這意味著他們必須多次輸入。
如果您確實必須執行您所描述的操作並且無法添加使用者名，則儲存該對的雜湊（SSN，密碼）。要檢查一個人的密碼是否正確，請檢查設置的成員資格 $ H(SSN, Password) $ 在雜湊表中*。無需像您可能想的那樣儲存 (H(SSN), H(password))。然後，您可以將 SSN 密文替換為 SSN+密碼雜湊。這樣做的缺點是您沒有一種純軟體方式來防止多次註冊。如果註冊涉及紙質表格和手動帳戶啟動，這可能不是問題。
如果您使用SSNS（例如必須保密的使用者名），我想不出一種使用 salt 的方法。通常，您使用非秘密資訊來查找鹽。如果您只使用密碼代替使用者名+密碼組合，您會遇到類似的問題。（也許減去密碼衝突問題）。添加使用者名或電子郵件可以讓您添加 salt。
您需要考慮允許自己在哪裡使用 SSN。只有客戶端？僅在 RAM 中？記憶體和硬碟？記憶體和固態硬碟？SSN 最終會被寫入交換空間嗎？休眠被禁用了嗎？故障轉儲會包含機密嗎？日誌？
（不幸的是，我不知道現實世界的公司真的對這些問題有任何想法。）
還要考慮：可以更改一個人分配的 SSN。分配給一個 SSN 的人員可以更改。
- 盡量了解實現細節。數據庫可能會洩露一些資訊。例如，刪除的行實際上可能不會導致數據被清除。在數據庫的磁碟表示中也可能有取證上有趣的資訊。（與歷史無關的資料結構相反。）
不要使用SSN 作為使用者名！！
像 FutureSecurity 一樣，我不能談論處理 SSN 的法律責任和各自的要求。以下建議是一般性的，可能適用於也可能不適用於 SSN 的合法儲存。
如果您的伺服器不需要知道，那麼它不需要儲存
$$ encrypted $$社會保障號。 要登錄，您應該使用具有確定性鹽和使用者選擇的密碼（可能在註冊時使用隨機密碼生成器）的客戶端記憶體硬密鑰派生函式。
如果使用者禁用了 Javascript，請使用
<noscript>免責聲明請求啟用 Javascript，如果未啟用，使用者的密碼將被發送到伺服器，並且將使用較弱的 HTTP cookie 並在 N 秒不活動後過期。$$ k = \operatorname{kdf}(\text{salt} = \text{service_unique_identifier} \mathop{|} \text{username}, \text{passphrase}) $$ 利用 $ k $ 在客戶端的“受信任”瀏覽器中獲取任意數量的秘密 $ \operatorname{kdf}_k(\text{“purpose”}) $ .
如果您確實需要 SSN，請給使用者 3 個選項：
- 每次需要時輸入 SSN。
- 加密 SSN 並將其儲存在瀏覽器的
localStorage- 加密 SSN 並將其儲存在伺服器上。
其中“加密”是經過身份驗證的加密，例如AES-PMAC-SIV。