Хранение данных кредитной карты

Ответ 1

В принципе, избегайте ответственности за сохранение данных CC на вашей стороне, однако я могу предположить, что вы используете службу третьей стороны для выполнения своей транзакции, такой как PayPal/Verisign или что-то еще, у большинства из них есть API, который позволяет вам для сохранения учетных данных CC на их стороне, и они вернут вам ключ, который затем вы можете использовать позже для завершения или инициирования транзакций, поэтому они позаботятся о трудной части, в то время как все, что вам нужно сделать, это сохранить этот строковый ключ в вашем БД.

Ответ 2

Я не считаю, что на самом деле незаконно хранить информацию CVV (в том смысле, что это противоречит любому закону), но это нарушает правила индустрии платежных карт, и они могут налагать любое количество различных санкций. Таким образом, ваши требования могут привести к тому, что вы не сможете принимать кредитные карты; - (

Ответ 3

Эндрю, вам нужно понять PCI-DSS - это небольшая задача. Лично я считаю это крайне неопределенным, но вот что я понимаю.

Во-первых, из описанного вами сценария я попытаюсь авторизовать карту на полную сумму, а затем, если это не удалось, я буду хранить информацию о клиенте (но не данные держателя карты), чтобы кто-то мог связаться с пользователем. Где я буду работать, некоторые из наших клиентов будут взимать только 1 доллар США, а затем немедленно аннулировать транзакцию, чтобы убедиться, что карта действительна. Затем они будут обрабатывать все заказы вручную.

Если вам нужно будет сохранить номер, вы получите успешное разрешение. Единственный номер, который вам нужен, это номер кредитной карты и код транзакции (по крайней мере, с каждым шлюзом, с которым я когда-либо работал).

Стандарт, последний раз, когда я смотрел на него, не является специфическим для алгоритмов шифрования, но вместо этого дает понять, что это должно быть в настоящее время нерушимое шифрование.

Теперь одна вещь, которую вы не можете сделать, это сохранить CCV после авторизации. Я понимаю, что вы можете сохранить его до авторизации, но я никогда не смогу привлечь никого, кто бы это написал в письменной форме. В принципе, вы авторизуете карту, вам лучше стереть ее.

И это не является незаконным на данный момент, но если вы будете прибиты, они принесут вам молот. Они в пределах своих полномочий могут наложить на вас тяжкие штрафы, но похоже, что они обычно делают, это значит, что вы исправляете. Если вы не соблюдаете, я не знаю, что происходит, потому что все, кого я слышал, это произошло. Но тогда они действительно поднимают вашу добычу с помощью микроскопа.

В конечном счете, я считаю, что их единственная палка, которую они действительно имеют, - это предотвратить вас от принятия кредитных карт. Большинство торговцев, с которыми я работал, боялись до смерти именно этого.

Ответ 4

Если вы собираетесь хранить информацию о кредитной карте, вам действительно нужно быть совместимым с PCI или вы просто просите о проблемах.

Сказав это, посмотрите на шифрование уровня ячейки, доступное в SQL Server 2005 и выше. Совпадение:) Недавно я представил презентацию с образцами T-SQL при шифровании с SQL Server 2005/2008, доступными здесь: http://moss.bennettadelson.com/Lists/Events/Attachments/9/June2008.zip (ссылка место обновлено 23 декабря 2008 г.)

Ответ 5

Если вы хотите сохранить строку в течение короткого периода времени в памяти, вы можете взглянуть на System.Security.SecureString.

Взято из этого answer:

Значения SecureString хранятся зашифрованными (скорее, запутанными), но, самое главное, они никогда не меняются на диск и могут быть удалены немедленно, когда вы закончите с ними.

Их сложно использовать, потому что вы можете создавать их только по одному символу за раз (чтобы побудить вас создавать их, захватывая нажатия клавиш, когда пользователь вводит свой пароль) и требуют восстановления трех строк кода, а затем уничтожить их простой текст, но при правильном использовании они могут сделать программу более безопасной, избегая уязвимости виртуальной памяти.

В конце примера SecureString преобразуется в регулярную управляемую строку, что делает ее уязвимой снова (обязательно используйте шаблон try-catch-finally для нулевой строки после того, как вы закончите с ней). Использование SecureString заключается в уменьшении площади атаки, ограничивая количество копий, которые собирает сборщик мусора, и уменьшает вероятность записи в файл подкачки.

// Make a SecureString
SecureString sPassphrase = new SecureString();
Console.WriteLine("Please enter your passphrase");
ConsoleKeyInfo input = Console.ReadKey(true);
while (input.Key != ConsoleKey.Enter)
{
   sPassphrase.AppendChar(input.KeyChar);
   Console.Write('*');
   input = Console.ReadKey(true);
}
sPassphrase.MakeReadOnly();

// Recover plaintext from a SecureString
// Marshal is in the System.Runtime.InteropServices namespace
try {
   IntPtr ptrPassphrase = Marshal.SecureStringToBSTR(sPassphrase);
   string uPassphrase = Marshal.PtrToStringUni(ptrPassphrase);
   // ... use the string ...
}
catch {
   // error handling
} 
finally {
   Marshal.ZeroFreeBSTR(ptrPassphrase);
}

Ответ 6

Это стоит где-то около 30 000 долларов, чтобы стать должным образом совместимым и иметь возможность делать такие вещи. Вам лучше использовать стороннее платежное обслуживание. Лично я рекомендую Element Express, и у них есть решение "Hosted", которое обходит PCI-DSS PAPDB. Мне пришлось конвертировать в это для моих собственных приложений, даже машины точки продажи! Это большая боль, но мы небольшая компания.

http://www.elementps.com/software-providers/our-security-edge/hosted-payments/PA-DSS-Certification-vs-Elements-Hosted-Payments/

В приведенной выше ссылке есть некоторая хорошая информация о расходах, связанных с получением соответствия. У нас были клиенты, которые просят нас хранить номера кредитных карт, и мы не будем этого делать, потому что мы можем быть оштрафованы. Нехорошо. Не открывайте себя на ответственности.

Edit:

Кроме того, если вы решите хранить информацию о кредитной карте, вам определенно нужно рассмотреть формы шифрования, которые вы собираетесь использовать. Симметричный? Асимметричный?

Если вы выполняете симметричное шифрование (Passkey), вы обнаруживаете серьезные уязвимости безопасности, если сервер (сайт), у которого есть ключ (необходимый для шифрования), каким-либо образом скомпрометирован. Помните, что даже скомпилированный код не будет скрывать текстовый ключ.

Если вы используете асимметричное шифрование (public/private keypairs), вы сталкиваетесь с некоторыми дополнительными проблемами, но если первичный открытый сервер сталкивается с угрозой, у них будет только открытый ключ, и если они также получат доступ к вашей базе данных.. они выиграли 't быть в состоянии decrpyt содержание.

Вопрос в том, где вы храните закрытый ключ? У вас есть кто-то вставить его с локальных компьютеров при запуске функций администратора. У вас есть отдельное приложение, которое работает на рабочем столе для просмотра заказов и т.д.

Есть много вещей, чтобы принять во внимание.

Заключительное примечание. Используйте платежный шлюз (Element Express, Authorize.NET, Paypal и т.д.) и не храните информацию о кредитной карте локально.: P

Вот ссылка об использовании асимметричного шифрования X509 в С#: http://www.csharpbydesign.com/2008/04/asymmetric-key-encryption-with.html

Ответ 7

Согласился, что вам следует избегать хранения данных, если сможете. Но, может быть, вы , третьей стороной? Если да, ознакомьтесь с стандартами PCI. Посмотрите немного на сайт, и вы найдете меры безопасности, которые вы требуется для реализации.

Ответ 8

Давайте рассмотрим это требование несколько иначе. В настоящее время это выглядит так:

Являясь владельцем продукта для веб-сайта X, я хочу, чтобы система временно хранила данные о деталях клиентов, чтобы я мог восстановить продажу, которая была отклонена компанией CC

Ppl имеет тенденцию думать так и запрашивать функции таким образом. Теперь я думаю, что ваше требование более удобно описать следующим образом:

Как пользователь, я хочу, чтобы веб-сайт X мог повторить платеж за мою покупку, поэтому у меня нет хлопот о том, чтобы пройти через процесс проверки снова, что является настоящей болью в...

Итак, нет явного требования для хранения чего-либо (на вашей стороне)? Его единственный подразумеваемый

Поставщики платежей могут предоставлять программные API-интерфейсы для вашей торговой учетной записи и возможность попытки повторного авторизации по отложенной попытке. я думаю, что @bashmohandes ускользнул от этого ранее

Не все поставщики платежей могут это сделать, но я думаю, что он зависит от их отношений с вовлеченными банками. Это то, что вы хотите избежать, т.е. имея тесные отношения с банками.

Сценарий 1: Предположим, что все, что я сказал, истинно

Вам не нужно хранить ничего, кроме ссылки на попытку авторизации. Некоторые поставщики платежей даже дают вам сладкий инструмент backoffice, поэтому вам не нужно делать свой собственный, чтобы делать повторные авторизации. Я думаю, что paygate делает это

Ваш лучший выбор, я считаю, это интервью с несколькими поставщиками платежей. они должны знать это, как задние части рук. Это потенциально решение с нулевым кодом

Сценарий 2: Предполагая, что я абсолютно ошибаюсь, но на законных основаниях это хранение файлов CC в порядке

Итак, вы должны временно хранить эти данные. Я советую:

• используйте двухсторонний метод шифрования (естественно), который не является специфичным для поставщика, поэтому вы можете использовать любой язык/платформу для шифрования/дешифрования.
• отделите службу шифрования/расшифровки от вашего приложения и обработайте ее как черный ящик
• использовать общедоступные/закрытые ключи для аутентификации для этой службы
• помещайте этот компьютер в частную сеть со своими собственными правилами брандмауэра (не обязательно должен быть аппаратный брандмауэр, но аппаратное обеспечение лучше).
• ваши серверы приложений свяжутся с этой машиной через ssl (вы можете уйти с самозаверяющим сертификатом, поскольку он находится в вашей частной локальной сети).

Все, что я предложил в сценарии 2, является препятствием, но в конечном итоге упорство выигрывает гонку, чтобы добраться до ваших данных. Единственный способ абсолютно защитить данные - отключить ваш сервер от эфира, но этот вариант немного радикален: -)

Сценарий 1 будет приятным. Не правда ли?

Ответ 9

Рассмотрите свои t-журналы!

Если вы объясните своему клиенту полное влияние (и исправление требований, если они обнаружены из-за соответствия), тогда поверьте мне, ваши "бизнес-требования" будут очень быстро меняться.

Если вы должны сохранить номер кредитной карты (и я выдвигаю мысль здесь, что нет разумного сценария, где вы должны), и вы намерены использовать встроенное встроенное шифрование для своей базы данных, подумайте об этом: как насчет вашего журналы транзакций?

Если ваши журналы транзакций могут отображать номер кредитной карты в ясной форме, тогда вы не соблюдаете и должны заплатить судебный аудит на вашем сайте от 10 000 до 50 000 долларов, если вас поймают. Бюджет для вашего собственного адвоката на случай, если ваш клиент подаст в суд на вас, потому что вы должны были знать все это.

Итак, если вы собираетесь хранить номер кредитной карты, запустите шифр в коде, чтобы журналы транзакций (вставка или обновление) отображали зашифрованную строку, а не номер карты в ящике.

И у вас даже нет поля или столбца в вашей базе данных для CVV - зашифровано или нет - этот судебный аудит покажет это (так будут журналы), а затем ваш клиент будет БОЛЬШОЙ, БОЛЬШОЙ проблемой. Они будут платить штраф и могут потерять способность принимать кредитные карты. Ваш адвокат будет очень рад.

Ответ 10

У меня есть сообщение в блоге, в котором говорится о такой ситуации хранения конфиденциальных данных в базе данных. Сообщение в блоге использует класс String Encryptor, который я построил с использованием алгоритма Triple DES, но вы можете подключить его, если хотите.

Сообщение в блоге содержит видео и исходный код, который использовался. Вы можете проверить это на http://www.wrightin.gs/2008/11/how-to-encryptdecrypt-sensitive-column-contents-in-nhibernateactive-record-video.html. Я думаю, что это определенно решит вашу проблему.