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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ни один из них не означает, что ваши данные совершенно безопасны, конечно.

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

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

прежде всего, если вы имеете дело с номерами кредитных карт, вам нужно будет стать РАЗЪЕМ PCI-ДСС совместимый, и как только вы сохраните номера, все 12 разделов спецификации PCI-DSS будут применяться к вам. Это большая стоимость для большинства организаций, и если у вас нет времени, ресурсов и финансовых средств, вы не должны идти по пути хранения номеров кредитных карт.

мы получили соответствие PCI-DSS в системе электронной коммерции на базе Windows, которая хранит кредитные карты. Он использует 256 битного шифрования AES. Сам ключ шифруется с помощью Windows DPAPI это означает, что он может быть расшифрован только процессом, запущенным под той же учетной записью пользователя, что и тот, который его зашифровал. Зашифрованный ключ хранится в реестре.

ключ вращается каждые 12 месяцев,а резервная копия ключа хранится разбитой на 3 части A,B, C и распространяется на 3 USB-накопителя, каждый из которых принадлежит другому человеку. Диск 1 имеет+Б, диск 2 Б+С, диск 3 имеет+С. Так что 2-х любых дисков необходимо построить полный ключ (A+B+C). Эта схема терпимы к потере 1 диски. Сами ключевые части шифруются паролем, известным только владельцу диска.

ваше предположение, что торговец должен хранить карту каким-то образом, неверно. Скорее всего, торговец хранит токен, который он получил от шлюза обработки платежей при первом использовании карты. Маркер однозначно идентифицирует комбинацию merchant и card. Впоследствии вы можете совершать покупки у этого продавца, не указывая номер своей карты снова. Если база данных продавца скомпрометирована, токены имеют небольшую ценность для злоумышленника. Они действительны только для этого торговца, и все они могут быть отменены сразу, когда будет обнаружено нарушение.

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

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

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

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

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

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

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