Common Mistakes on PAN Generation

The prime focus of the PCI DSS is on protecting the card number also known as the PAN (Primary Account Number) besides the PIN and Track data (Chip and Mag Stripe). The standard allows the entity to store the PAN whereas it prohibits storage of Track data and PIN with exceptions for issuers of the card. For display the the standard allows the display of the first 6 and the last 4 digits of the card number. But are we kind of secureing something that is readily predictable?

So one of the first steps involved in the entire payment lifecycle is the generation of the card number. How much of this first step is addressed in the PCI DSS standard is worth examining with the standard being live for about a decade now.

Is it addressed in the standard?

Yes it is, and there is no doubt about it although the term “Generate” is not specifically included in the applicability clause of PCI DSS. The applicability clause covers storage, processing and/or transmission. However the inclusion of generation of card number can be done from the reading of requirement 3 and also references to the issuers and issuing function in the PCI DSS standard. Do you think it should be included specifically; We would leave that to the reader’s judgment

So that brings us to the question what is so critical about generating the card number? We think it is fundamental and basic to the whole edifice of the PCI DSS standard because the standard is purely focused on the protection of the card number generated and used.

With that undisputed importance to the generation of the card number, we need to see how the card number is generated? Obviously in almost 100% of the cases the number is generated by an application or software or a utility whatever you may choose to call.

In a 16 digit card number, the application used for generating the card number can “play around if allowed” only at the maximum on the 9 digits starting from the seventh to the fifteenth. This is because the first 6 digits is the BIN (Banker Identification Number) and the last that is the 16th digit in case of a 16 digit card number is the check digit calculated to conform to the MOD10 algorithm.

When we say “play around if allowed” it all surfaces to how the application is designed to generate the card number. Some of the scenarios are discussed below:-

Scenario 1

There could be a case where in even out of the nine free digits two to three digits are frozen meaning thereby they are already predetermined and fixed to indicate some services/branding that would be available for particular type of card like Gold card or Platinum card. This reduces the free play of generation of a card number and prefixes become overbearing. Also in such cases the hiding of those two to three digits becomes difficult because various operators processing card transactions would require them or promoting card benefits programs or loyalty programs. The hiding is relevant because only the first six and the last four can be displayed as per the standard. In practice we have found many entities wanting to display the first six and the last six digits for operational purposes. While it can be allowed under the exception clause of PCI DSS standard there are risks attached to such exposure arising out of method of generating the card number

Scenario 2

It is quite possible especially in today’s core banking environment some of the 9 free digits of the card number (debit or credit) are picked up from the account number or a function of account number allotted to the customer. Say the middle 9 digits of the 16 or 15 digit core banking account number. There may not be many entities really protecting the account numbers any way near the fashion laid out in the PCI DSS standards for card numbers

Scenario 3

In some scenario it may be found that only one bin is used at a time and exhausted in full before the next bin is taken and on top of that the numbers are assigned serially.

The above scenarios and many others similar or worse than above lends predictability of the card number that could be issued and defeats the purpose of hiding/protecting the same post generation as per the PCI DSS standard. Readers must be aware that the first six digits of card number are in public domain and identifies the bank (Issuer) to which it belongs.

The above discussion bring us to the most important point, that is, the card number generated ( free digits ) should be as random as possible and from different bins that the issuer may own subject of course to the optimum use of the bin. Let us not be in a situation of hiding something that is readily predictable.

The application or software or utility used should be a part of the PCI DSS scope. The greater the randomness in the generation of the card numbers the lesser is the risk of its predictability and should be a part of the Risk assessment as specified in the PCI DSS standard.

Going forward with the standard already laying down the requirement of additional controls when hashed values of card numbers are stored, it would not be impertinent to suggest the shift from numeric card numbers to alpha numeric card numbers that will increase the randomness in geometric progression or to a completely different authentication mechanism but warrant a sea of change in devices like ATM, POS, Online Portals etc expecting and accepting traditional payment technologies.

The same is true for PIN,CVV and CVV2 in terms of length, complexity or in alternative technologies, That will be covered in the next blog we will write. Keep reading and keep suggesting for moving towards a more secure card eco system spearheaded by PCI DSS.

Leave a Reply

Your email address will not be published. Required fields are marked *