хранение информации о кредитной карте

Question

Поэтому я хотел бы изменить приложение PHP / MySQL, чтобы надежно хранить кредитную карту, но не данные cvv и банковского счета. PCI DSS требует 1024 RSA / DSA. Небольшому количеству пользователей будет предоставлен закрытый ключ для расшифровки пакетного файла информации об учетной записи для ежемесячной отправки обработчикам платежей. Мне неясно, возможно ли иметь систему, которая позволила бы пользователям, которые вошли в систему с обычными 8-значными паролями, безопасно изменять данные своей учетной записи. Кажется, что это невозможно, и шифрование должно быть односторонним (т. Е. Каждый пользователь -> администраторы; никогда не разрешать пользователю снова расшифровывать свою собственную информацию), при этом информация об учетной записи никогда не предоставляется пользователям даже через SSL-соединения. Или есть правильный и простой способ сделать это, о котором я не знаю, это PCI DSS-совместимость?

Answer 1

Вам может быть легче, если вы различаете данные хранилище , доступ и передача .

Хранение требует сильного обратимого шифрования; данные бесполезны, если вы не можете их получить.

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

1. Храните данные с секретным ключом, который никогда напрямую не раскрывается ни одному пользователю. Конечно, вам нужно где-то хранить этот ключ , и вы должны быть в состоянии получить его.
2. Когда каждый пользователь выбирает пароль, используйте пароль, чтобы зашифровать личную копию личного ключа этого пользователя. ( Примечание: даже если вы шифруете каждую копию ключа, проблемы безопасности могут возникнуть из-за хранения нескольких копий одной и той же информации .)
3. Не хранить пароль пользователя. Вместо этого хэш это в соответствии со стандартными рекомендациями (с солью, и т. Д. ) и хранить хэш.
4. Когда пользователь вводит пароль для входа в систему, хэшируйте его и сравнивайте с сохраненным значением. Если они совпадают, используйте пароль (в виде простого текста) для расшифровки ключа, который затем используется для расшифровки фактических данных.

Передача данных через безопасное соединение, такое как SSL. Разумно (возможно, необходимо) разрешить пользователям получать доступ (и изменять) свои собственные данные, если вы продолжаете следовать рекомендациям.

Комментарии:

• 8-значный пароль подразумевает пространство ключей 10 ⁸ ~ 2 ²⁷ = 27 бит, что по современным стандартам довольно ужасно. Если вы не можете использовать более длинные (или буквенно-цифровые) пароли, вы можете рассмотреть возможность добавления дополнительных слоев.

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

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

Удачи!

Answer 2

PCI DSS не требует 1024-битного RSA для шифрования. В более старых версиях спецификации упоминались AES и 3DES по именам, но я считаю, что более новые версии просто указывают на сильное шифрование. Большинство людей используют AES 256.

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

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

Ingrian (теперь SafeNet) предлагает достойное предложение для сети HSM. Он будет управлять ключами для вас и выполнять криптографические операции. Также возможно использовать интеграцию шифрования на уровне БД, чтобы вам вообще не пришлось менять приложение. (Хотя, на мой взгляд, шифрование на уровне БД сомнительно безопасно.)

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