Шифрование номеров кредитных карточек

Kirill

Новичок
Hello!
Есть задача хранить данные кредиток клиентов в БД. Задался вопросом, стоит ли шифровать?
Предположим, данные хранятся в зашифрованном виде в БД. Ключ хранится в конфиге (или генерируется, но смысл от этого не поменяется).

Виды угроз:
- SQL injection/дамп потерялся по тупости админа/etc - данные зашифрованы, все счастливы
- недобросовестный исполнитель - есть доступ к БД, нету доступа до ключа (ключ хранится в конфиге на сервере) - все счастливы, данные в безопасности
- взлом с возможностью доступа до файлов - все в жопе :)

С PDO sqlInjection маловероятен, недобросовестный исполнитель - вопрос философский. Возникает вопрос, а нужен ли вообще это геморой с шифрованием?
 

craz

Нестандартное звание
Имхо нет, у меня в логах на устройствах ******************8994 - вот так примерно написано, а когда какая-то фигня происходит я все равно узнаю номер карты)
 

fixxxer

К.О.
Партнер клуба
Работа с номерами банковских карт регламентируется PCI DSS. Вот и ознакомься, что там по этому поводу говорится. Более того, не пройдя сертификацию, ты не имеешь права вообще ничего с этими номерами делать. Без сертификации - любой банк или процессинг пошлет тебя лесом^W на свою страничку, где и будет осуществляться ввод пользователем, ты же будешь получать уведомления (где максимум будет 4 последние цифры номера карты).
 

Kirill

Новичок
Работа с номерами банковских карт регламентируется PCI DSS. Вот и ознакомься, что там по этому поводу говорится. Более того, не пройдя сертификацию, ты не имеешь права вообще ничего с этими номерами делать. Без сертификации - любой банк или процессинг пошлет тебя лесом^W на свою страничку, где и будет осуществляться ввод пользователем, ты же будешь получать уведомления (где максимум будет 4 последние цифры номера карты).
Читал в ине-те об этом, но странно что компания, которая будет обрабатывать платежи, не предъявляет никаких требований, кроме как юридических (договор с пользователем, правила возврата, док-ты юр. лица/etc).

ха ха ха

Но вывод, конечно - жесть.
Если все запросы пишутся в стиле "column_id = :columnId", то вероятность того, что кто-то напишет "column_id = {$id}", довольно низкая.
 

С.

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

fixxxer

К.О.
Партнер клуба
Kirill
Ну а какие еще требования? Ты же просто ставишь ссылку на их страницу оплаты, тебе сообщается только результат.
А вот к компании, которая будет обрабатывать платежи, требования огого.
Ну и требования на самом деле есть, только этим занимается risk management банка/процессинговой компании. С левым оффшором тебе просто откажут в открытии мерчант-аккаунта - штрафы то, если что, в конечном итоге выплачивать банку и процессинговой компании. По сути огромные штрафы это основной механизм фрод-регулирования у МПС ;)
 

Kirill

Новичок
я же написал, что данные нужно хранить. И вопрос про шифрование.
Обрабатываться они будут через внешний сервис, на вход ему передаются данные карточек, на выходе результат true/false. В том то и дело, что хранить их надо в локальной БД.

Это добрая традиция форума, принимать топик стартера за дибила :D
 

MiksIr

miksir@home:~$
я же написал, что данные нужно хранить. И вопрос про шифрование.
Обрабатываться они будут через внешний сервис, на вход ему передаются данные карточек, на выходе результат true/false. В том то и дело, что хранить их надо в локальной БД.

Это добрая традиция форума, принимать топик стартера за дибила :D
Так может есть за что?
Вызываете вы мастера металическую дверь с замком ставить, а он начиает вас спрашивать - а замок куда ставить то вообще, там где петли или с другой стороны? А как крепить дверь - на пену или может просто прислонить? Вот как-то так вы выглядите. Полный ноль в защите финансовой информации, а туда же.
 

Kirill

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

С.

Продвинутый новичок
я же написал, что данные нужно хранить. И вопрос про шифрование.
Обрабатываться они будут через внешний сервис, на вход ему передаются данные карточек, на выходе результат true/false. В том то и дело, что хранить их надо в локальной БД.
Не имя докторской, но 7-летний опыт специлизации на ПС, заявляю, что это мошеническая схема.
 

akd

dive now, work later
Команда форума
Kirill, в отличие от тебя, тут многие знают по опыту как работать с картами и что можно хранить, а что не очень. но ты умничай, умничай ..
 

craz

Нестандартное звание
А да я ж в банке работаю) поэтому они у меня не зашифрованные)
 

fixxxer

К.О.
Партнер клуба
я же написал, что данные нужно хранить. И вопрос про шифрование.
Обрабатываться они будут через внешний сервис, на вход ему передаются данные карточек, на выходе результат true/false. В том то и дело, что хранить их надо в локальной БД.

Это добрая традиция форума, принимать топик стартера за дибила :D
Для не дебилов повторяю: чтобы разместить у себя на сайте форму, где вводится номер карты, необходима сертификация МПС на соответствие PCI DSS.

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

Если речь идет о США, то там все проще, но надо иметь юрлицо в США
 

fixxxer

К.О.
Партнер клуба
Вот как после таких топегов верить в надежность электронных платежей по кредиткам...
Знаешь... говорят, что работники колбасных комбинатов не едят колбасу :)

PayPal и инет-банк-клиент своего банка - ок, все остальное - стремно, да =)
 
Сверху