低熵資料與信用卡雜湊的安全邊界（APAC）
目錄
一個令人不安的事實：雜湊不等於保護。你可以儲存信用卡號的 SHA-256 雜湊值，完全符合 PCI DSS，卻實際上毫無保護可言，因為你雜湊的那個值根本不含足以抵禦暴力破解的熵。
這會讓平時很嚴謹的工程團隊栽跟頭，因為雜湊感覺上是安全的。雜湊是單向的，原值無法透過反推函式還原，所以資料理應是受保護的。問題不在雜湊本身，而在於你餵給它的是什麼。
用真實數字看熵的問題 #
16 位卡號不是隨機的。它的結構是公開且固定的：
- 前 4 到 6 位是髮卡行識別碼（IIN）：銀行字首，完全公開。
- 最後一位是校驗位，由 Luhn 演算法計算得出，這個公式 1954 年就發表了。它不是秘密，只是錯誤檢測。
再按 PCI DSS 常見允許的方式遮蔽 PAN：前 4 到 6 位和後 4 位可見，中間 6 到 8 位隱藏：
4532 AAXX XXXX 1234
IIN 已知 4 位的情況下，未知部分是8 位數字，即至多 100,000,000 種可能。套用 Luhn 校驗後只有十分之一能存活。你真正的搜尋空間是 1,000 萬個值。這不是一個密碼，這是一份很短的清單。
測試 1,000 萬個雜湊需要多久？ #
接下來情況會更糟。SHA-256 在設計上就是快的。它是為千兆級速度的完整性校驗而生，而不是為儲存秘密。現代 GPU 破解跑分是公開且可復現的：
| 硬體 | 大致 SHA-256 吞吐 |
|---|---|
| 1× RTX 4090 GPU | 約 85 億次雜湊/秒 |
| 4× RTX 4090 叢集 | 約 340 億次雜湊/秒 |
| 8× RTX 4090 叢集 | 約 680 億次雜湊/秒 |
1,000 萬次猜測除以每秒 85 億次，大約是千分之一秒。一塊消費級顯示卡就夠了。甚至一臺單 GPU 的電腦都能用彩虹表在眨眼之間"反解"出一個信用卡號。
結論很直白：合規不等於安全。**對於低熵欄位，即便是 SHA-2（或 SHA-3）也不安全，即使它合規。**函式確實是單向的，但當輸入空間極小時，它會被輕而易舉地窮舉殆盡。把 SHA-256 換成 SHA-512 或 SHA-3 解決不了問題，因為它們同樣快。
“合規"真正允許的是什麼 #
PCI DSS 其實並沒有要求你用 SHA-256 雜湊 PAN。要求 3.5 說的是你必須用強密碼學使 PAN 不可讀，並明確點名了帶金鑰的雜湊和加密，同時指出：只要鹽值保密、雜湊不具備現實可逆性，加鹽雜湊索引是可以接受的。問題在於，對一個只有 1,000 萬值空間的裸 SHA-256 而言，窮舉在實踐中就等於可逆，因此它違背了要求的本意，哪怕檢查表上打了勾。
遮蔽（顯示前 4-6 位和/或後 4 位）是另一項獨立控制：它保護的是操作員看到的內容，而不是你儲存的內容。兩者極易混淆，而這種混淆正是"已遮蔽但未加鹽雜湊"的 PAN 混進生產環境的原因。
如何正確保護這類資料 #
修復方法是用對待密碼的態度對待低熵欄位，因為在數學上它們一樣弱。按優先順序排序：
- **乾脆不要儲存它。**將 PAN 令牌化，把真實號碼儲存在獨立的保險庫或 HSM 中。如果你從不儲存這個值，就沒有什麼可以被暴力破解。
- **帶秘密 pepper 的 keyed hashing（HMAC）。**如果必須以 PAN 為索引，使用 HMAC，並將高熵金鑰儲存在資料庫之外。沒有金鑰，無論輸入熵多低，暴力破解在算力上都不可行。
- **記憶體困難型密碼雜湊。**當你只能靠值本身來保護值時，使用 Argon2id（RFC 9106）或 scrypt，配合每個值的隨機鹽和調校過的引數，讓每一次猜測都消耗真實的時間和記憶體。比如 64 MB 記憶體成本的 Argon2id，能把那次 0.001 秒的窮舉變成數月的 GPU 時間。
- **到處使用鹽和 pepper。**每個值的隨機鹽可以擊敗預計算的彩虹表；只要保守住秘密，pepper 可以徹底擊潰離線攻擊。 OWASP 密碼儲存速查表 和 NIST SP 800-63B 正是出於同樣的原因，推薦對低熵機密使用記憶體困難型函式。
卡片之外的啟示 #
這條原則適用於一切熵受限的定長識別符號：國民身份證號、電話號碼、出生日期，甚至是生成不佳的 API 金鑰。如果輸入空間很小，雜湊函式的速度就是你的敵人，而"合規"絕不是"安全"的同義詞。
我們的 API 與應用安全審查 會檢視你的程式碼實際如何儲存和傳輸敏感值，並且我們會直截了當地告訴你：哪裡透過了檢查表，卻仍在暴露真實資料。