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

Question

以下是我們用來存儲CC詳細信息的模型嗎？

我們所有的信息都使用公鑰加密進行加密，並且密鑰對是依賴於用戶的（它在服務器上生成並且私鑰使用數據庫上的哈希處理的用戶密碼進行對稱加密）因此，基本上首先運行用戶通過SSL連接發送密碼，密碼用於添加salt以生成MD5哈希，密碼也用於加密私鑰並將私鑰存儲在服務器上。當用戶想要付款時，他會發送他的密碼。密碼解密私鑰，私鑰解密CC的詳細信息並收取CC的詳細信息。

Answer 1

如果用戶的密碼足夠安全以保護私鑰，爲什麼不跳過私鑰並使用密碼（通過a suitable key derivation algorithm）加密信用卡號？不必要的併發症肯定會做不是提高安全性。

該方案不使用公鑰作爲任何事情，表明在這裏不對稱算法不合適。

Answer 2

這將信用卡的安全性與用戶密碼的強度聯繫起來，用戶密碼因用戶而異，且通常較弱。最好創建自己的對稱加密密鑰，保持安全，然後doing a bunch of complicated stuff that experts invented, involving initialisms like CBC, CTR, and IV。

Answer 3

我同意埃裏克森的觀點，即如果沒有使用公鑰，那麼做非對稱加密就沒有意義。

一如既往，這裏的問題是一個密鑰管理問題。不安全感來自於不知道如何安全地隱藏解密數據的密鑰。

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

如果你不能，你應該找到一個合適的地方來存儲你的「主」鍵，一個可能的例子是windows的存儲（如果這是可能的話）。不過，我承認我真的不知道windows商店有多安全。

Answer 4

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

不知道你爲什麼要使用公鑰加密，這可能會很慢。此外，每個用戶的1個密鑰對的模型可能無法縮放（多少個文件，您可以爲公鑰操作生成參數）。請注意，您可能有濫用行爲 - 人們檢查他們的被盜卡片列表是否良好。

通過添加您自己的主密鑰並從組合中導出密鑰計劃，您仍然可以防止在用戶不在場時使用任何卡號。一般來說，大多數商家不能遵循這個嚴格的要求，因爲當用戶不在場時有需要使用卡號。

如果您只是想要用戶特定的密鑰（並且您每次都必須使用不同的IV），那麼您可以使用openssl EVP_BytesToKey路由並每次傳遞一個不同的salt與加密密鑰和iv的主密鑰（並且它們對於每個用戶而言將是不同的）。

支付工具的最終使用受所描述的用戶密碼的保護。一些用戶選擇弱密碼。所以你可能想要使用額外的校對來確保卡片屬於用戶 - 這些都是爲了你自己的好處，因爲你可以打擊友好的欺詐退款並保持低的真實欺詐退款。

Answer 5

你可能想給你看的支付卡Industryies「付款申請DSS」」 https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

它可以幫助做出一些決定你。