Есть ли безопасный способ гарантировать уникальность кредитной карты?

Question

Итак, как и в любом другом достаточно грамотном магазине веб-разработок, мы надеваем хлопковые перчатки, когда прикасаемся к кредитным картам, и используем Braintree SecureVault для их хранения, чтобы избежать проблем с соответствием PCI.

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

Две лучшие идеи на данный моментявляются:

A) Хранение хэшей изолированно в наборе, безотносительно к их платежной информации.Поэтому, если хэши взломаны, все, что у них есть, это список номеров кредитных карт, которые использовались в определенный момент времени, без какой-либо личной информации или сведений о том, является ли он еще действительным.Основным недостатком здесь является то, что у нас есть запись последних 4, которые потенциально могут быть использованы для их сопоставления до некоторой степени.

B) Хеш без полного числа и работа с ложными положительными и отрицательными сторонами.Хеширование на name, last-4 и expiration должно быть довольно уникальным.Ложный позитив - это как выигрыш в лотерею, мы можем справиться с ним в службе поддержки.Ложное отрицание может быть вызвано изменением имени, нам не ясно, какие у нас есть гарантии относительно точности сопоставления имен (на мой взгляд, это может повлиять как на шлюз, так и на торговый счет), поэтому это может открыть лазейку.

Мысли?Предложения?Испытанная в бою мудрость?

Answer 1

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

Во-вторых, вы заново изобретаете колесо. Существует множество «магазинов приложений» (интернет-магазин Chrome, магазин Android, магазин приложений iTunes и т. Д.), Которые предоставляют встроенные механизмы для оплаты и пробных периодов. Использование этих систем повысит наглядность вашего продукта для потребителей, предложит вашим потенциальным клиентам несколько различных способов оплаты (делая их более склонными к покупке), а также избавит вас от хлопот, связанных с внедрением этого механизма самостоятельно. Кроме того, пользователи обычно предпочитают выдавать свою кредитную карту как можно меньшему числу компаний; вам не только придется самостоятельно реализовывать этот сложный механизм, но и заставить пользователей достаточно доверять вам, чтобы использовать его.

Нижний уровень: детали реализации
Любой механизм хеширования может иметь коллизии, поэтому вам все равно придется решать эту проблему. Очевидно, вы должны использовать полное шифрование диска и другие передовые методы обеспечения безопасности на ваших серверах. Риск одновременной компрометации базы данных и алгоритма соления может быть уменьшен путем размещения службы базы данных на отдельном компьютере, отличном от того, на котором размещен этот код. Основной уязвимостью хеширования являются атаки методом грубой силы. И лучший способ справиться с ними - просто сделать грубое форсирование достаточно дорогим, чтобы злоумышленнику это не стоило. Использование отдельной соли для каждой записи (например, имя клиента, почтовый индекс клиента и т. Д. В качестве части соли) сделает использование радужных таблиц неэффективным. Конечно, само по себе создание данных менее ценными для злоумышленников (например, не включая полный номер кредитной карты) также является хорошим способом противодействовать такого рода атакам. В любом случае, я снова советую вам воспользоваться множеством магазинов приложений, а не реализовывать это самостоятельно.

Answer 2

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

Я не уверен, еслиэто нарушит PCI или что-то еще (я так не думаю, но могу ошибаться)