Шифрование данных

Было бы полезно знать сервер БД и типы языка / платформы, чтобы мы могли получить более конкретную информацию, но я бы посмотрел на SHA.

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

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

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

Если вы используете Oracle, вас может заинтересовать Прозрачное шифрование данных. Однако доступно только с лицензией Enterprise.

У Oracle также есть утилиты для шифрования - дешифрования, например DBMS_OBFUSCATION_TOOLKIT.

Что касается «Стандартов», то соответствующий стандарт, который вас интересует, - это стандарт PCI DSS, который описывает, какие меры необходимо предпринять для защиты конфиденциальной информации о кредитных картах.

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

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

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

Когда нужно действовать по номеру кредитной карты?

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

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

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

Просмотрите свои требования, действительно не так много случаев, когда вам нужно хранить информацию CC

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

Большинство компаний называют это чем-то вроде «Управление профилями клиентов», и на самом деле они взимают довольно разумную плату.

Несколько известных мне поставщиков (в произвольном порядке):

• Authorize.NET Менеджер по работе с клиентами
• Цитадель TrustCommerce
• BrainTree

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

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