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

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

10 голосов
/ 12 сентября 2008

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

То, что мне нужно, это способ защитить эту информацию даже на уровне базы данных, чтобы никто не мог войти и создать файл номеров карт. Как другие преодолели эту проблему? Каков «стандартный» подход к этому?

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


Ну, база данных ORACLE, поэтому у меня есть PL / SQL и Java для игры.

Ответы [ 10 ]

8 голосов
/ 12 сентября 2008

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

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

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

5 голосов
/ 12 сентября 2008

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

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

4 голосов
/ 12 сентября 2008

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

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

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

3 голосов
/ 12 сентября 2008

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

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

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

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

1 голос
/ 12 сентября 2008

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

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

1 голос
/ 12 сентября 2008

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

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

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

0 голосов
/ 04 июня 2010

Я бы попытался объяснить, но эта статья неплохо справляется.

http://www.di -mgt.com.au / cryptoCreditcard.html

0 голосов
/ 12 сентября 2008

Вот что мы делаем: Как ваши конфиденциальные данные зашифрованы в базе данных? Таким образом, даже если вы украдете наши серверы базы данных web +, вы не сможете их расшифровать

0 голосов
/ 12 сентября 2008

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

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

0 голосов
/ 12 сентября 2008

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

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