Проверка безопасности: номер кредитной карты клиента хранится на сервере, но в файле cookie клиента хранится одноразовое шифрование - PullRequest
0 голосов
/ 02 апреля 2009

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

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

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

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

Дайте мне знать, где, по вашему мнению, эта схема ужасно рушится.

Ответы [ 4 ]

2 голосов
/ 09 декабря 2011

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

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

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

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

1 голос
/ 02 апреля 2009

Технологически: ошибочно.

С юридической точки зрения: возможно, с недостатками. поговорить с адвокатом.

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

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

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

0 голосов
/ 02 апреля 2009

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

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

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

...