2010-02-10 211 views
23

我即將繼承和設計一個設計很差的小型商業零售網站。除此之外,最令人關注的是目前的信用卡處理。在線信用卡存儲?

目前,所有者從在線訂單中檢索信用卡信息(姓名,號碼,CVV2和到期日期),並將所有信息以明文形式保存在MySQL數據庫中。然後通知將被髮送到他的電子郵件,有人已經下令。此後,他有一個管理後端頁面,他查看他用來與他自己的商家離線處理的訂單和信用卡信息。

從後端頁面檢索信息後,信用卡號碼和CVV2立即被刪除(自動調用PHP腳本)。如果該頁面在7天內未被訪問,該信息也將被刪除。因此,在事務處理之前七天內,所有信息都有可能以純文本形式存在數據庫中。

這似乎不是一個好的設計,可能是非法的。如果它是非法的,我將不得不將這件事告訴他,因爲他還沒有意識到這一點。

我的問題:除了不安全之外,這是非法還是違反使用條款(PCI DSS)?如果是這樣的話,我怎麼能向他證明這一點,以便他能夠改變他的方式(顯然,我不想把我的手放在非法的東西上。另外,有時使用條款的措辭可以似乎是主觀的)?最後,解決此問題的最佳選擇是什麼(第三方在線商家,符合PCI DSS標準或其他)?

+1

你在哪個國家? – 2010-02-10 22:10:37

+0

我在美國。 – 2010-02-10 22:25:24

+4

我投票結束這個問題作爲題外話,因爲它是一個法律問題,而不是一個編程問題。 – durron597 2015-05-26 18:49:20

回答

21

這違反了PCI DSS。你不僅要存儲你不應該存儲的信息(CVV),而且你還沒有加密信用卡號碼(也是違規行爲)。

其中規定所有網上交易必須使用ECI兼容設備或軟件網上訂單處理更糟糕的是他違反了Visa和MasterCard準則必須有一個獨立的商家帳戶。他們的信用卡終端絕對不是ECI兼容的,因爲沒有。他們需要獲得一個新的商家賬戶,並使用像Authorize.Net這樣的支付網關來處理這些訂單。

編輯

因爲我懷疑webbsite所有者實際上會打擾得到一個新的商家帳戶或實現支付網關你最好的選擇是使用兩個單向加密來存儲這些信息。然後確保他們用於檢索信用卡信息的頁面已加密(SSL證書),以確保信息的端對端安全。

我強烈建議您獲取Internet商家帳戶並使用支持網關(如Authorize.Net)。除了符合PCI和ECI標準並且是一種聰明的方式之外,企業不僅可以失去商家賬戶,還可以將其列入黑名單,並禁止再次擁有真實的商戶賬戶。所有這一切都需要他們的商戶賬戶提供商承擔一部分費用,以便意識到他們正在做的事情以及開始的麻煩。

+0

ECI合規性是否屬於這種情況?他不是在線交易,而是在線獲取信息以離線完成交易。這有點像通過電話接收信用卡信息來執行交易。和/或你是否說這需要另一個商家帳戶? – 2010-02-10 22:37:39

+2

ECI合規性是一個問題,因爲訂單是通過其網站發起的。如果它通過電話發起ECI不適用。基本上,這不是你如何處理訂單,而是它來自何處。它還需要另一個商家賬戶,因爲源自互聯網的訂單必須與非互聯網訂單分開。這主要是由於退款問題。 – 2010-02-10 22:46:27

+0

這很有道理。謝謝。 – 2010-02-10 22:50:01

0

這絕對是違反PCI規則。但是,向存儲的數據添加加密應該不會那麼困難,特別是如果人類不得不查看它的話很少見。

在爲第三方信用卡交易處理公司工作之後,如果他們的系統很糟糕,我強烈建議您。但是,您仍然需要加密該信息,或者在將其發送到TPP後根本不存儲它。 TPP確實適合商戶,因此他們可以幫助您解決任何合規問題,並幫助您獲得最佳的交換率。

2

有很多爲您處理所有安全和合規性問題的第三方支付提供商。

對於任何中小型企業而言,這是一項必須外包給專業人士的功能。

2

使用第三方信用卡處理網關不需要在客戶端的服務器上存儲信用信息 - POST'ed cc信息被傳遞給處理網關,處理網關返回可用於記錄保存的事務ID由您的客戶。

信用卡支付網關由諸如Authorize.net,LinkPoint Central等公司提供 - 即使PayPal正在進入遊戲。所有主要網關都有現成的代碼,用於將購物車與大多數流行的Web編程平臺(.NET,PHP,Java等)集成。此外,大多數主要購物車支持開箱即用的主要網關,或者至少爲大多數網關提供可安裝的模塊。

所以,你的客戶應該得到一個互聯網支付網關設置,你應該將他們現有的代碼與網關集成在一起。

1

正確保護支付數據是一個複雜的話題。即使是非常大的公司有時也會從他們的系統中竊取大量信用卡。

至少,這裏要考慮的步驟:

  • 確保在線訂單使用HTTPS來捕獲數據。
  • 如果數據庫和Web服務器是不同的盒子,請確保它們之間有安全的路徑。
  • 加密數據庫中的付款數據。 MySQL Reference
  • 確保強大的訪問控制,後端的網頁(是向外界物理訪問?是否需要一個強壯的密碼嗎?它是HTTPS?)
  • 確保沒有日誌(如調試日誌)是最終將支付信息寫入文件系統。
4

這是嚴重違反PCI規則。您可以在這裏獲取文檔:https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml 去Google Checkout之類的第三方或類似的網站會很聰明。成爲符合PCI要求的人很頭疼,需要年度評估(可能是自我評估),其中可能包括滲透測試等。如果你真的檢查過,他可能根本不需要訪問信用卡信息,只需要交易ID。您不僅需要對數據進行加密,還必須有詳細的方案來保護加密密鑰。這比小企業想要的要大得多。上面的一些建議聽起來不錯,但它不符合PCI規範。閱讀文件,你會很快看到這是一個大的事業。我目前支持一個內部PCI兼容系統,並且不得不花費大量精力來達到標準。我們也必須進行一些網絡更改。將業務轉換爲第三方會更便宜。