關於存儲信用卡詳細信息的安全模型的思考

Question

這是我們用來存儲CC詳細信息的模型，它看起來有多安全？

我們所有的信息都使用公共密鑰加密進行加密，並且密鑰對取決於用戶（在服務器上生成的信息和使用用戶密碼對稱加密的私鑰也使用哈希在數據庫中加密），因此基本上在首次運行時，用戶發送通過SSL連接的密碼，密碼與添加鹽一起使用以生成MD5哈希，密碼也用於加密私鑰，並且私鑰存儲在服務器上。 當用戶想要付款時，他發送密碼。 密碼解密私鑰，私鑰解密CC詳細信息，並收取CC詳細信息。

Answer 1

如果用戶的密碼足夠安全以保護私鑰，為什么不跳過私鑰並使用密碼（通過適當的密鑰派生算法 ）來加密信用卡號呢？ 不必要的並發症肯定不會提高安全性。

該方案不使用任何公共密鑰，這表明此處使用了不對稱算法。

Answer 2

這將信用卡的安全性與用戶密碼的強度聯系在一起，用戶密碼的強度因用戶而異，通常較弱。 最好先創建自己的對稱加密密鑰，並保持安全，然后再進行專家發明的一堆復雜的事情，包括CBC，CTR和IV等初始化 。

Answer 3

我不確定您是否將卡號和私鑰文件存儲在一起。 似乎僅通過使用用戶密碼來加密私鑰文件，就意味着如果加密的私鑰文件可用，就為字典式攻擊打開了大門。

不知道為什么要使用公鑰加密，這可能會很慢。 同樣，每個用戶1個密鑰對的模型可能無法擴展（可以為公共密鑰操作生成多少個文件參數）。 請注意，您可能有虐待行為-人們會檢查被盜卡列表是否正確。

通過添加您自己的主密鑰並從組合中得出密鑰時間表，您仍然可以在不存在用戶時阻止使用任何卡號。 通常，大多數商家不能遵循此嚴格要求，因為在用戶不在時確實需要使用卡號。

如果只需要用戶特定的密鑰（並且每次都必須使用不同的IV），則可以使用openssl EVP_BytesToKey路由，並每次使用將從其派生加密密鑰和iv的主密鑰傳遞不同的密碼。對於每個用戶，它們將有所不同）。

最后，付款工具的使用僅受所述用戶密碼保護。 一些用戶選擇弱密碼。 因此，您可能需要使用其他打樣來確保卡屬於用戶-其中一些是為了您自己的利益，因為您可以與友善的欺詐扣款抗爭，並降低真實的欺詐扣款。

Answer 4

我同意埃里克森的觀點，即如果不使用公鑰，那么進行非對稱加密是沒有意義的。

與往常一樣，這里的問題是密鑰管理問題。 不安全性源於不知道如何安全地隱藏用於解密數據的密鑰。

我不確定是否可行，但是如果您負擔得起，可以購買硬件安全模塊，然后讓HSM管理密鑰，或者使用HSM主密鑰對所有客戶（專用）密鑰進行加密。

如果不能，則應該找到一個合適的位置來存儲“主”密鑰，一個可能的示例是Windows存儲（如果可能的話）。 但是，我最承認我並不真正知道Windows存儲的安全性。

Answer 5

您可能需要看一下“支付卡行業”的“支付應用程序DSS”” https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

這可能有助於您做出一些決定。