3 Ways 8-Digit BIN Ranges May Impact PCI Compliance

By David Gamey - 11 Apr 2017.

Tags:

blog
pci
x

New 8-digit Bank Identification Numbers (BIN) could complicate PCI truncation rules and create compliance headaches for those required to maintain compliance. Many organizations build their PCI compliance around DSS requirements and how they use cardholder data. A common strategy to simplify compliance uses Primary Account Number (PAN) truncation to make cardholder data unreadable. PAN truncation rules haven't changed much since the early DSS. Today, organizations can keep the first 6 and last 4 digits of PAN (6-4/*). So, any rule changes could affect merchants, service providers, and many others.

Update: In December 2021, the PCI DSS truncation rules were changed to mitigated many issues identified in this article, for more details please see https://controlgap.com/blog/8-Digit-BINs-Great-PCI-Truncation-Reset

PCI Truncation Today

Before considering changes, stakeholders should also be aware of all current truncation requirements:

PCI truncation keeps the first 6 and last 4 digits. This works for all major card brands (see FAQ #1091).
Other regulations have truncation rules. Microsoft was recently fined by the FTC for violating FACTA which allows only the last 5 digits in customer receipts (this doesn't apply to internal reports). As FTC rules also apply to non-US companies doing business with US citizens, they and can apply to companies headquartered in Canada, Europe, and the rest of the world. This is an example of a law trumping PCI.

Recently the card brands proposed two changes to help card issuers. The first extended the length of PAN to 19 digits. The second allowed for longer 8-digit BINs. These proposals will change PCI truncation rules. Masking rules shouldn't change as they deal with displays and not a storage.

When we originally saw these, we expected straightforward and easy to implement truncation rules. We imagined combining today’s rules with a first 8 and last 4 rule for the new 19-digit PAN (8-4/19). However, these proposals aren't linked and the possibility of 8-digit BIN with 16-digit PAN could create implementation and compliance challenges.

Notably Visa's bulletin on page 6 contains the following on the continued use of 16-digit PAN and PCI (note the underlined text):

Data Presented on Screens and Reports: PCI DSS provisions already allow users with a legitimate business need to see any or all of the PAN digits. No changes are expected to accommodate the expansion of the BIN length.

Data at Rest: Clients that use truncation as their only method of complying with the PCI requirement for protecting data at rest will need to add one or more of the other acceptable methods for data protection, such as encryption, hashing or tokenization.

Today's truncation rule destroys 6 digits. So, an attacker has a 1 in 100,000 chance of guessing the original PAN (the other 900,000 numbers fail the Luhn test). These odds permeate most PCI guidance and set a risk threshold. The table below shows how fictional PAN truncated under different rules would look:

PAN	Rule	Trancation	Strength	Compliance
9234567890123455	6-4/16	923456xxxxxx3455	1 : 100,000	PCI 3.2
923456789012349	6-4/15	923456xxxxx2349	1 : 10,000	PCI 3.2
9234567890120	6-4/13	923456xxx0120	1 : 100	PCI 3.2
9234567890123455	0-4/16	xxxxxxxxxxxx3455	1 : 50,000,000,000	PCI 3.2 and FTC (customer receipts)
9234567890123456787	6-4/19	923456xxxxxxxxx6787	1 : 10,000,000	PCI 3.2 compliant
9234567890123455	8-4/16	92345678xxxx3455	1 : 1,000	Not PCI 3.2 compliant
9234567890123456787	8-4/19	92345678xxxxxxx6787	1 : 1,000,000	Visa, MasterCard, but not PCI 3.2 compliant

Possible Updates And Changes

Clearly either the rules for truncation or the risk tolerance of the card brands must change. If so, some key questions include:

Implementation uncertainty raises stakeholder concerns.
- Could PAN truncated under today's rules, come back into scope under new rules?
- Would stakeholders need to clean up old data?
How will this affect applications that rely upon truncated data?
- New truncation rules could break applications that rely upon characteristics (e.g. a low collision rate) of today's truncated values.

Consider these possible rule changes (see update note for 2017-5-10 below):

Last 4 might break applications.
First 6 and last 4 cuts off new BINs. Full 8-digit BINs might be considered cardholder data needing DSS protection.
First 8 and last 4 might be too risky for the card brands to accept.

Many of these possible rules could be disruptive and have unforeseen and costly implications to:

Format preserving encryption and tokenization
Payment applications and middle-ware including customized and approved PA-DSS applications
Back-end systems
Analytic systems
Databases and reporting systems
Payment Terminal applications

Changing payment terminals can be expensive. Recent examples include:

Ongoing retirement of PTS v1.0 terminals starting 2014
Forced deprecation of RSA 1024 certificates in 2014
Ongoing SSL and early TLS migration for vulnerable terminals staring 2015
Forced migration from SHA-1 certificates 2016
Upcoming retirement of PTS v2.0 terminals starting 2017

We believe the payments industry needs to look at this important change as soon as possible. Stakeholders must understand the impact of any new truncation rules. In our opinion, the rules need to clear, simple, and easy to implement with a minimum of ambiguity and impact.

We hope this article leads to further industry discussion, analysis, and consensus.

Note: Updated 2017-4-21 to cite Visa Bulletin on Data at Rest

Note: Update: 2017-5-10 The PCI Council today clarified the truncation rules but issues and risks remain.