Обзор безопасности: кредитная карта клиента #, хранящаяся на сервере, но с одноразовым шифрованием, хранящимся в клиенте cookie

Question

Я пишу систему, в которой, как обычно, клиент просит удобства «запомнить данные вашей кредитной карты».

Я сказал им, что это, по всей вероятности, не-идет. Тем не менее, у меня была хорошая идея (tm) только сейчас, и, видя, что Good Ideas in Encryption (tm) на самом деле являются плохими идеями (tm), я подумал, что рассмотрю здесь и посмотрю, какие дыры можно пробить через это.

По существу, я думаю об информации кредитной карты плюс некоторую подпись сообщения, используя одноразовый блок, созданный для каждого клиента. Эта панель хранится в качестве переменной cookie в браузере клиента. В следующий раз, когда пользователь попытается разместить покупку, блок отправляется на сервер, и если сервер может правильно декодировать свои зашифрованные данные, он показывает информацию о кредитной карте как уже заполненную. (Информация cc фактически не передается обратно). Сервер никогда не будет хранить блок в чем-либо больше, чем в памяти или файле страницы. Фактически, я намерен отправить блокнот дважды: один раз по прибытии на страницу CC (где сервер проверяет, следует ли запрашивать информацию CC) и один раз на отправке CC для получения фактической информации.

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

Сообщите мне, где вы думаете, что эта схема ужасно терпит неудачу.

Answer 1

Хранение накладной клиентской панели оставляет ее уязвимой для XSS, я бы подумал.

Answer 2

Технологически: недостатки.

Юридически: возможно, недостатки. поговорите с адвокатом.

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

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

Answer 3

Если кредитная карта хранится на стороне клиента, тогда вы храните ее с ключом, что означает, что она уязвима.

Если вы храните серверный сервер кредитной карты, вам не нужен ключ ключа шифрования, хранящийся на клиенте.

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

Answer 4

Звучит отрывочно, и я уверен, что вы злоупотребляете термином «одноразовая панель».

Вместо того, чтобы идти по этому маршруту, изучите использование службы, например, Authorize.net's Customer Information Management. В основном вы даете им информацию о карте, и они вернут вам идентификатор, который вы можете использовать для оплаты карты. Идентификатор привязан к торговому счету веб-сайта и не может использоваться для взимания платы с любого другого торговца.

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

Примечание: Я не поддерживаю Auth.net или его CIM. Это просто пример, с которым я знаком.