Мне нужно создать суррогаты кредитных карт (токены), сохраняющие формат

Question

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

1) Количество цифр в суррогате такое же, как реальный номер карты (PAN). 2) Тип карты эмитента - первые 1,2 или 4 цифры в суррогате остаются такими же, как и в исходном PAN. 3) Последние 4 цифры суррогата остаются неизменными (в целях обслуживания клиентов.) 4) Суррогат проходит проверку Luhn mod10 на наличие синтаксически действительной кредитной карты.

Я с готовностью справлюсь с требованиями 1-3, но № 4 поставил меня в тупик! Окончательная реализация будет либо t-sql, либо c #.

Есть идеи?

Answer 1

@ neo имеет правильный ответ (+1 к вам), но я просто хотел отметить, что если я понимаю, что вы делаете правильно, это кажется «плохой идеей». Идентификационный номер эмитента (IIN) - это первые шесть цифр PAN. Если вы хотите сохранить первые шесть и последние четыре цифры, я не думаю, что у вас возникнет проблема ( Правила PCI заявляют, что вы можете хранить их в незашифрованном виде), но смоделируйте средние шесть (или более ), и убедитесь, что они проходят проверку luhn , вполне возможно, что вы будете дублировать реальный номер карты. Кроме того, у вас возникнет правильная головная боль, пытаясь доказать аудитору , что вы НЕ храните реальные номера карт.

Может быть лучше переосмыслить imho. Из вашего вопроса непонятно, зачем вам номер, который проходит проверку Луна и выглядит как настоящая карта, но на самом деле это не так.

Edit:

Исходя из комментариев в вашем ответе, вы можете создать свой суррогат, взяв первые шесть и последние четыре цифры реальной карты и заменив все остальные цифры на 0. Затем пропустите это через проверку Луна. Если он недействителен, измените последний ноль на 1 и попробуйте снова. Продолжайте увеличивать эту цифру, пока не получите правильный номер. Вам нужно сделать это не более 9 раз. Его сырой и может быть оптимизирован , но он будет работать.

Answer 2

В каждом номере кредитной карты есть контрольная цифра.Он рассчитывается по алгоритму Луна .Пример C # - здесь .

Answer 3

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

Например, если начальная цифра (и) не соответствует соответствующему типу карты (4 = виза, 37 = AMEX, 6011 = обнаружить и т. Д.) Многие системы электронной торговли и выставления счетов также проводят быструю семантическую проверку с использованием Алгоритм Луна. Если я передам им суррогат, который не проходит этот тест, то он может быть отклонен. Наконец, хотя они не хотят хранить исходную PAN по причинам PCI DSS, они обычно хотят последние 4 цифры из соображений обслуживания клиентов.

Я приму ваши мысли под совет; в идеале, я бы предпочел создавать суррогаты, которые НЕ проходят тест MOD 10, так как это легче защитить, но я должен знать о потребностях поставщика клиента.

Что касается самого алгоритма Луна, я рассмотрел детали этого алгоритма, а также алгоритм Грэма Митчелла для генерации Луна, пропускающего «поддельные» числа. Однако его алгоритм не ограничен - он не начинается с 1-й цифры и последних 4-х фиксированных, тем более что последняя цифра сама является контрольной суммой.