I need to generate credit card surrogates (tokens) that are format preserving.

Question

For an eCommerce application I need to take a credit card and use the real card for passing through to a payment gateway but I need to store, and return to the transaction initiator, a surrogate that is format preserving. Specifically, this means:

1) The number of digits in the surrogate is the same as the real card number (PAN). 2) The issuer type part of the card -- the initial 1,2 or 4 digits remains the same in the surrogate as in the original PAN. 3) The final 4 digits of the surrogate remain the same (for customer service purposes.) 4) The surrogate passes the Luhn mod10 check for a syntactially valid credit card.

I can readily handle requirements 1-3 but #4 has me completely stumped! The final implementation will be either t-sql or c#.

Any ideas?

Answer 1

There is a testing digit in every credit card number. It is calculated by the Luhn algorithm. An C# example is here.

Answer 2

@neo has the correct answer (+1 to you) but I just wanted to point out that if I understand what you're doing correctly, it seems like a 'bad idea'. The issuer identifier number (IIN) is the first six digits of the PAN. If you want to store the first six and last four digits, I dont think you'll have a problem (PCI rules state you can store those in plaintext), but by mocking up the middle six (or more) digits, and ensuring they pass the luhn check its entirely possible you'll be duplicating a real card number. Further you'll get into a right headache trying to prove to an auditor that your NOT storing real card numbers.

May be best rethinking imho. Its not clear from your question why you need a number that passes the luhn check and looks like a real card, but isnt really.

Edit:

From the comments in your answer you could generate your surrogate by taking the first six and last four digits of the real card and replacing all other digits with 0. Then run that through the luhn check. If its invalid then change the last zero to 1 and try again. Keep incrementing that digit until you get a valid number. You'd need to do this 9 times at most. Its crude and could be optimised, but it would work.

Answer 3

The problem with using a surrogate number that fails the Luhn algorithm test is that when you go to replace the real PAN with the surrogate in one of any number of host applications, those applications themselves have some logic in place that might accept/reject the surrogate or trigger behavior based upon attributes in the surrogate.

For instance, if the initial digit(s) doesn't represent an appropriate card type (4=visa,37=AMEX,6011=Discover,etc.) Many ecommerce and billing systems also do a quick semantic validation using the Luhn Algorithm. If I hand them a surrogate that fails this test then it might be rejected. Finally, while they don't want to store the original PAN, for PCI DSS reasons, they usually do want the last 4 digits for customer service reasons.

I will take your thoughts under advisements; ideally, I'd prefer to create surrogates that DO NOT pass the MOD 10 test since this is easier to defend but I have to be aware of client vendor needs.

With respect to the Luhn Algorithm itself, I have looked at the details of the algorithm and also Graham Mitchell's algorithm for generating Luhn passing "fake" numbers. However, his algorithm is unconstrained -- it doesn't start with the 1st digit and last 4 digits fixed, especially since the last digit is itself the checksum digit.