8 digit BINs and PCI DSS

On April 1, 2022, the payment brands Visa and Mastercard will expand the BIN (Bank Identi­fi­cation Number) of their cards worldwide from 6 to 8 digits. In future, the first 8 digits of a 16-digit credit card number (Primary Account Number, PAN) will be used to identify the card issuer. The BIN is used in many occasions where the use of the full PAN is not necessary — e.g. for routing of trans­ac­tions, or for reporting.

BINs and PCI DSS 

Wherever a full PAN is used, the systems, environ­ments, processes and people must meet the require­ments of the data security standard PCI DSS (Payment Card Industry Data Security Standard). As useful as the protection of the PAN by the PCI DSS is – it is not necessary for the BIN. The PCI DSS therefore describes the condi­tions under which parts of the PAN do not require the same protection as the full PAN. If not the full PAN is stored, processed or trans­mitted, but only parts of it, the PCI DSS refers to “truncation”. If the full PAN is stored in the background, but not all digits are displayed in an appli­cation, the PCI DSS refers to the display as “masking”. In everyday life, the term “crossing out” is also used for the two different measures; from PCI DSS point of view, however, they have to be differentiated.

The following rules previ­ously applied to truncation and masking:

  • Masking: PCI DSS Requirement 3.3 states that a maximum of the first six and last four digits (“first 6, last 4”) of the PAN may be displayed, as long as there is no business need to view the full PAN.
  • Truncation: PCI DSS Requirement 3.4 lists truncation as an example of rendering PANs unreadable, but does not define it. The permitted formats are rather defined by the inter­na­tional payment card organi­za­tions and get summa­rized by the PCI SSC in FAQ entry #1091. Most of them had agreed on the rule “first 6, any other 4”, which had lasted for many years.

Changed rules for truncation and masking 

However, due to the switch to 8‑digit BINs and the need for many companies to process them, the payment brands have now changed their speci­fi­ca­tions. The current summary in the PCI SSC FAQ entry now defines that “first 8, any other 4” is permitted for truncation for 16-digit PANs. The (test) card number 4012888888881881 is then allowed to be stored and processed in the form 40128888xxxx1881, for example — it is suffi­cient if any four digits are crossed out after the BIN. Only for shorter PANs, the existing rules “first 6, any other 4” (Discover) or “first 6, last 4” (American Express) remain in place. A corre­sponding adjustment of the PCI DSS requirement for masking is expected with the change to PCI DSS v4.0.

From a security point of view, removing so few digits is not an improvement — but from a business perspective, the change is probably necessary. It is to be hoped that, overall, this will be offset by other security measures.
In any case, the require­ments of the PCI DSS will not prevent the use of 8‑digit BIN in the future.

Caution when combining different formats 

Regardless of the length of the BIN, merchants and service providers who work with truncated card data should take care not to weaken the protection by mixing different formats.

  • It must be considered that the extended truncation formats only apply to 16-digit PANs. The length of the PAN must therefore be taken into account for truncation during storage.
  • Truncation formats such as “first 6, any other 4” theoret­i­cally allow the existence of different truncated versions of the same PAN. The above card number might be stored as 40128888xxxx1881 in one system and 401288888888xxxx in another. This is not prohibited — but it must be ensured that no one without an according business need can merge the two versions and thus recon­struct further digits of the PAN — right down to the complete card number.
    This also applies if different formats are used for masking and truncation.
  • If both truncated PANs and the hash values of PANs are stored in an environment, the two values themselves are initially uncritical. However, if the truncated PANs and their hash values can be related, the original full PAN can be easily recon­structed using rainbow tables. In this case, additional measures must also be taken to prevent the two versions from being merged.

PCI DSS v4.0 is coming — an overview

The PCI DSS (Payment Card Industry Data Security Standard) is well known as a compre­hensive data security standard for payment card data of the inter­na­tional payment brands. The Payment Card Industry Security Standards Council (PCI SSC) keeps revising the standard throughout the years to address evolving risks and threats to payment data, to keep pace with the ever changing IT and payment landscape, and to reinforce security.
The PCI SSC has been working on the new, funda­men­tally revised version 4.0 of the standard for a long time now. After three RFC phases throughout the years, the new version will now be officially published on the PCI SSC website in March 2022.
Several changes have already been announced and are listed hereafter.

New validation options 

PCI SSC plans to add more flexi­bility to the standard. Tradi­tionally, the intended way of fulfilling a PCI DSS requirement is to follow it word by word. Now, the PCI SSC plans to add a choice: For nearly each requirement, an entity can either choose the tradi­tional way of fulfilling it word by word, or they can use a customized validation.
For each requirement in the standard, the objective that is intended to be reached with it will be given. If an entity thinks that they want to use another way of meeting this intention than following the requirement word by word, they can document how they do this. This includes a risk assessment to verify the appro­pri­ateness of the customized way. This documen­tation, including the risk assessment, is then provided to the assessor, and the assessor identifies suitable testing proce­dures to verify the imple­men­tation of the customized controls.

Requirement changes

To make sure PCI DSS compliance is kept up throughout the year, additional require­ments are announced by the PCI SSC, e.g. the necessity for

  • Defin­ition of roles and respon­si­bil­ities for all PCI DSS relevant topics; and for
  • Regular verifi­cation of PCI DSS scope.

In addition, existing require­ments will be adapted to threat and security evolvement. Changes to require­ments on the following topics are forecasted:

  • Authen­ti­cation requirements,
  • Detection mechanism and awareness measures for ongoing threats, and
  • Risk assess­ments.

Also the use of 8‑digit BINs will need to be addressed (see our blog entry).
Of course, the exact details of changes can only be given after the final publication.

Transition process

The PCI SSC has announced a transition period of two years, plus additional transition time for completely new requirements.

So after publi­cation in March 2022, take your time to read the new PCI DSS version, identify the changes, and under­stand the impact on your environment. Use this year to plan migration to PCI DSS v4.0 and decide when is the right moment for your entity to switch from version 3.2.1 to 4.0.

Your PCI DSS consultant or assessor can help you under­standing the intention of changes, your need for migration, and the validation require­ments. Please do not hesitate to contact them. If you do not have direct contact to a PCI DSS expert, please contact SRC’s PCI DSS respon­sible.

To get a first overview of the changes to the standard, you can also join our free PCI DSS v4.0 webinar on 20th of April: Register here.

PCI DSS v4.0 release delayed

PCI DSS v4.0 release delayed

The publi­cation of a new, funda­men­tally revised version of the payment trans­action standard PCI DSS has been announced since 2019. We are eagerly awaiting the changes that the new version will bring.

After PCI DSS v4.0 had already undergone two RFC phases in 2019 and 2020, the PCI Security Standards Council has now decided to also initiate an RFC phase for supporting documents, in particular for

  • the template for the Report on Compliance (ROC),
  • the template for the Attes­tation of Compliance (AOC), and
  • the self-assessment question­naires (SAQs)

in June 2021. However, this will also delay the publi­cation of PCI DSS v4.0.

Instead of the announced release period in Q2 2021, the aimed period of final­ization is now Q4 2021. The actual release date has not yet been specified.

We must therefore be patient a little longer before we can properly plan the migration. With the shift of the publi­cation date, the planned transition periods from PCI DSS v3.2.1 to v4.0 have also been postponed. We are therefore also postponing our PCI DSS v4.0 webinars to 2022.

SRC-Expertin Ehlers: Standards of the Payment Card Industry (PCI)

SRC-Expert Ehlers: Standards of the Payment Card Industry (PCI)

“PCI compliance requires know-how and resources.” SRC expert Jana Ehlers explains the different PCI security standards in an article which has just been published on the profes­sional platform “All About Security”.

In view of the increasing number of card payments in pandemic times, the protection of payment card data is a very current topic.

All PCI standards aim at protecting payment card data of inter­na­tional payment systems. The most well-known standard alone, PCI DSS, has around 250 individual require­ments. If these are already taken into account when setting up networks and struc­tures, there is often no need for complex and expensive retrofits. But also the permanent mainte­nance of PCI DSS conformity poses challenges for companies.

SRC examines and advises on PCI standards since their emergence in 2006. This experience can be used to correctly under­stand and consider the inten­tions of the PCI standards. SRC accom­panies through the whole process. Thus, not only PCI-conformity can be achieved in an under­standable way, but also a great deal more security for the customers’ payment card data worthy of protection.

SRC recognized as SPoC/CPoC Lab by the PCI SSC

SRC recog­nized by PCI SSC as SPoC and CPoC Security Lab

Today, the worldwide operating PCI Security Standards Council has recog­nized SRC as the fourth laboratory for the perfor­mance of security tests for SPoC and CPoC solutions.

With SPoC solutions (Secure PIN Entry on Commercial-off-the-Shelf devices) a merchant can accept payments with commer­cially available mobile devices.

While the SPoC program describes solutions with PIN entry, the CPoC program is aimed exclu­sively at contactless solutions that do not require PIN entry.

A SPoC solution consists of four core components

  • a Secure Card Reader for PIN (SCRP), an external and PCI PTS approved card reader,
  • a tested PIN CVM App for secure PIN entry on the merchant’s standard mobile device,
  • the retailer’s mobile device (COTS device) such as a smart­phone or tablet, and
  • a background system that contributes signif­i­cantly to the security of the overall system by means of attes­tation, monitoring and processing.

With CPoC, the PCI SSC has developed require­ments for solutions for processing contactless payments without PIN entry (“Tap and Go”) on commer­cially available mobile devices (commercial off-the-shelf, COTS), such as smart­phones or other mobile commercial off-the-shelf (COTS) devices with NFC interface.

With the SPoC and CPoC programs, the PCI SSC meets the increasing demand for new and secure accep­tance solutions and ensures security in the accep­tance of payments via mobile phones and tablets. The corre­sponding tests are now also carried out by SRC.

The recog­nition of SRC as a lab for the programmes SPoC and CPoC is an important signal to the market. Customers from this innov­ative environment can now also make use of SRC’s expertise for the devel­opment of secure payment solutions.

PCI DSS guidance for Large Organizations

PCI DSS best practices guidance for large organi­za­tions published

SRC Security Research & Consulting GmbH contributed to the most recent PCI (Payment Card Industry) Security Standards Council Special Interest Group (SIG). The resulting guidance on PCI DSS for Large Organi­za­tions is now published.

Complex organi­za­tions, corpo­ra­tions and companies often face specific challenges when imple­menting PCI DSS (Payment Card Industry Data Security Standard) require­ments: the hetero­geneity of their infra­struc­tures and processes, the constant change of corporate struc­tures, and dealing with diverse require­ments, respon­si­bil­ities and management tasks.
The new guidance on PCI DSS for Large Organi­za­tions helps large and/or complex organi­za­tions coordinate and manage their PCI DSS activ­ities across multiple environments.

  • PCI DSS guidance for Large Organi­za­tions //document.