Кто-то хранит данные кредитной карты - как они делают их?

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

Чтобы ответить на ваш конкретный вопрос, можно сохранить ключ шифрования кредитной карты на диске в зашифрованном виде. Ключ шифрования ключа может быть получен из парольной фразы, которую необходимо ввести при запуске сервера. Схема разделения секрета Шамира может использоваться так, чтобы k из N общих ресурсов требовались для создания секрета, который будет использоваться в качестве ключа шифрования ключа. Затем расшифрованный ключ / секрет шифрования сохраняется в памяти. Если необходимо перезапустить сервер, вам потребуется k общих ресурсов. Это, конечно, большие накладные расходы, и большинство продавцов, которых я знаю, не реализуют этого. Однако они обычно хранят ключ отдельно от зашифрованных данных для некоторой промежуточной защиты, поэтому доступ к одному не означает автоматически доступ ко второму целиком (хотя все еще очень плохо).

Я удалил содержимое своего исходного сообщения, поскольку оно не давало прямого ответа на вопрос. Достаточно сказать, что управление ключами и правильное шифрование - важная часть, но все же небольшая часть истории.

Аудиторы PCI не могут гарантировать, что все сделано правильно.

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

Думаю, это лучше, чем ничего.

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

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

Если вам нужен быстрый поиск вместе с обратимым шифрованием, используйте оба варианта: хэш и шифрование.

Изменить: Похоже, мой ответ вызывает разногласия. Я хотел бы отметить следующее очень интересное эссе с сайта Integrity.com (PDF):

Хеширование номеров кредитных карт: небезопасные методы применения

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

Да, необработанный хеш карты небезопасен; вот почему мы солим наши хэши! Но статическая соль также небезопасна, они позволяют создавать радужные таблицы для известных статических солей. Так что лучше всего изменять наши соли каким-либо непредсказуемым образом. В случае паролей достаточно использовать отдельный случайный хэш для каждого проверяемого пароля; он может даже находиться в той же таблице / строке, что и хешированный пароль. В случае кредитных карт это должно быть то же самое - случайная соль для каждого экземпляра хэшируемой кредитной карты. Если номер кредитной карты хранится для каждой транзакции, отдельная соль для каждой транзакции.

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

Минусы находятся в поиске; невозможно эффективно найти конкретный номер кредитной карты во многих транзакциях.

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

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

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

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

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

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

Конечно, ни то, ни другое не означает, что ваши данные полностью защищены.

Как продавец, вы можете хранить данные CC в своей собственной базе данных или передавать их сторонним поставщикам.
Сторонние поставщики, такие как IPPayments или крупные банки, такие как Westpac в Австралии, соответствуют уровню 1 PCI. Для веб-приложений вы можете выбрать использование веб-страницы приема платежей (представленной где-нибудь в рабочем процессе вашего клиента) с их фирменной символики для вашей компании. Для приложений Windows (например, приложения CRM вашей компании) и регулярных платежей у них обычно есть шлюз, который можно использовать с помощью их API, который предоставляет услугу токенизации, то есть они принимают номер CC, регистрируют его и возвращают уникальный токен, который просто выглядит как номер CC. . Токен можно безопасно хранить в вашей БД и использовать для любых дальнейших транзакций, пакетных платежей, сверки и т. Д. С банком. Конечно, большая проблема - это операционные затраты на транзакцию. Для коммунального предприятия, которое принимает ежемесячные платежи по кредитной карте от миллиона клиентов, транзакционные издержки могут быть значительными.

Если вы решили сохранить номер CC в своей собственной БД, достаточно тройного шифрования DES. Лучшим вариантом для вас является прозрачное шифрование в базе данных, предлагаемое Oracle Advanced Security или SQLServer, где даже администратор базы данных не может расшифровать номер CC. Кроме того, существует обременительная ответственность за управление ключами, резервное копирование, физическую безопасность, сетевую безопасность, передачу SSL, изменение настроек по умолчанию для всего серверного оборудования и брандмауэра, антивирус, аудит, камеры безопасности и так далее ...

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

Если вы собираетесь использовать симметричное шифрование, то вы попадаете в новую сферу сложностей, которые сводятся к управлению и контролю над ключами расшифровки. Замечу, что даже если вы хэшируете номера кредитных карт, вам все равно придется иметь дело с обратимым шифрованием, поскольку вся PII (Personally Identifiable Information) должна быть зашифрована. SQL Server 2008 имеет новую архитектуру плагина Extensible Key Mangement, которая позволяет использовать программы сторонних производителей для управления контролем над ключами расшифровки, включая разделенные ключи.

Дополнительная информация: Развертывание SQL Server 2008 на основе стандартов безопасности данных индустрии платежных карт (PCI DSS) версии 1.2.