PCI Council And Passwords: Do As We Say, Not As We Do

Written by Evan Schuman
February 24th, 2010

The council’s own passwords wouldn’t pass PCI rules. The PCI Council has never been a stranger to irony. But its internal password procedures—the ones that protect the PCI Standard itself (literally the Word document version of the standard)—may be taking the encrypted irony cake. Those procedures actually violate at least four PCI requirements, plus a few standard security rules.

First, to be fair, what’s being protected is not especially sensitive. Specifically, the password is not intended to keep out prying eyes. Rather, its sole purpose seems to be to keep meddling fingers away. The Council apparently doesn’t want anyone out there to be able to edit the standard and then to produce the modified file as proof of a particular position. The password often frustrates people who have to work with the document, though, because it prevents them from copying a section and forwarding that text to someone.

But in an attempt to protect the integrity of the document—which tells retailers how to maintain payment card security, including, deliciously, rules for setting passwords—the Council decided to lock it down before posting it on the PCI Web site. PCI’s rules require passwords to be changed every 90 days, prohibit group/shared/generic passwords and require passwords to be at least seven characters long and contain both numeric and alphabetic characters.

Additional rules, typical for any security shop, include prohibiting passwords that are in the dictionary and certainly ones that are easily guessable. And yet, the password for the PCI DSS document seems to violate the four password rules contained in its words (that’s about as quintessentially ironic as anything could get), in addition to the dictionary and guessable rules. It’s—wait for it—pcidss.

When one QSA was asked about the password, he guessed it on his first try—once he was told that it was quite guessable. He then tried the same password on some PCI FAQs, and it worked. (Same password for multiple files? That’s got to be in somebody’s password rules somewhere.)

As mentioned earlier, these documents don’t include credit card numbers or other sensitive information. But if the decision is made to lock them down, there’s presumably a reason. If the concern is that QSAs or merchants can change the document, then the Council needs to choose a password that will indeed create the desired protection.

That said, another unwritten rule is that passwords need to be changed the moment a breach occurs or the password otherwise gets out. StorefrontBacktalk‘s PCI Columnist, Walt Conway, and I have a bet on how long it will take the PCI Council to change its password after this story is published. Want a piece of the action?


14 Comments | Read PCI Council And Passwords: Do As We Say, Not As We Do

  1. Preston Says:

    If they don’t want the document changed, they should save it as a PDF and be done with it.

  2. Evan Schuman Says:

    Not necessarily. PDFs today can be edited quite easily, unless they have password-protection activated, in which case you’re back to the same issue again. Besides, the council DOES offer these documents as PDFs already.

  3. Harry Maggiore Says:

    Given they do not collect store or transmit card holder data, they are not subject to the specification.

  4. Evan Schuman Says:

    True, but that’s not the point. If they have chosen to password protect a file, it’s interesting that they didn’t adhere to their own recommendations. Compliance is not the issue. As we–and tons of others–have noted, PCI is not just for payment. Officially, of course, it is, but the guidance, guidelines and best practices contained in PCI is a good tool for anyone to use when needing to protect any kind of data. Lots of companies are using their suggestions to secure CRM data and many other kinds of information. The irony here is that the PCI Council didn’t opt to use its own advice.

  5. A reader Says:


    From the association that was created to inflict tissue-paper security protocols on the rest of the world, and whose mandate is to punish organizations that don’t build a proper steel safe to guard their used tissues?

    Their foundations were built on irony. Why are you so surprised?

  6. bill bittner Says:

    One of my pet peaves with passwords is the 90 day rule. That, more than anything else I would imagine, is the reason you find passwords written on the back of postit notes attached to monitors.

  7. Robert L Santuci Jr. Says:

    At least it appears that they’ve removed the spot for credit card information from their fax forms.

  8. Dave CISA/M/SP Says:

    PCI applies to the storage, processing and transmission of cardholder data, and nowhere else. Provided there is no cardholder data in a given segment, that environment can be placed out of scope for PCI. This article seems to further assume that not only is the Council storing cardholder data, but they haven’t segmented their network to take the zone where this article is stored out of scope.

    The idea of a standard implies uniform application. There is no expectation that we deploy PCI across zones that are out of scope. Ergo there should be no expectation the Council do otherwise. There is enough expense, confusion, difficulty, concern, criticism, and mud-slinging in this environment already. Neither increasing the scope, cost, and complexity of PCI to areas out of scope, nor expecting the Council to act differently than those its standards govern, advances the cause of Information Security in general or cardholder data security in particular.

  9. Frank Says:

    As an ex IT auditor (you never really become an ex auditor) I have several comments on this particular non issue. First of all I feel that the document should be one that the PCIDSS has in their possession with their own security. I really don’t see the purpose or the reason to password protect the document. If a level whatever credit card processor wants to make changes to the document and they compare the original with the one submitted this would in my view be fraud and subject to some very serious fines.

    In another light I see this as one of the better standards as it does require companies and Government agencies to become better at security. To me it’s like the intro class to IT security for the dummies of management who have no clue how to spell security.

    As far as the audits are concerned. I hope not to be disappointed. But we’re being audited by KPMG for PCI compliance. This is like Auditor appreciation week as we’ve decorated the office with all things for the auditor. The sign in sheet we put up at the computer room door with badges the Friday before the auditors come in. Management here thinks auditors are just stupid. And personally if these young wet behind the ears auditors buy off on all these fake decorations I have lost all faith in audit.

    It appears they are asking some pretty interesting questions which indicate a lot of follow up to what I see as dead ends. Which I hope they address.

    The problem to me is that in the past when auditors draft their findings they usually get fired. Then two years later we get a few more new kids come in with their check lists. I really hope these ‘kids’ are good at what they do, else management will celebrate how well they can pull the wool over the eyes of children.

  10. Carsten Says:

    Harry Maggiore, can i get this in writing ?
    >Given they do not collect store or transmit card >holder data, they are not subject to the specification.

    i have proven to my QSA that we do not collect any card holder data within our system except for the last four digits… and i am still required to implement all 12 PCI requirements throuhout the whole IT landscape and infrastructure.
    Yes, we are a retailer, and yes, we do a lot of credit card business… but we do not store card holer information other than the ccPAN masked, with only the last 4 digits visible. But that doesn’t seem to be enough to be PCI compliant ?

    the irony in the PCI council though, as mentioned in the article… very enjoyable. :-)

  11. Richard Haag Says:

    @Carsten – you are forgetting the “Transmit” portion of scope which likely applies to you.

    In general QSA’s have know how to unlock this document for a very long time(Insert Object –> Select file). I am not sure why they choose to lock it in the first place, but they have been doing this for years.

    I do not think it is a fair statement to suggest that the council is following bad password practices for something as meaningless as protecting the integrity(vs confidentiality) of a document. There is a big difference in terms of value(and risk) in using weak passwords on a POS system and using a weak password to protect a document.

    Now if someone were to hack into their portal and execute a successful SQLinjecton attack, that would be ironic.

  12. Evan Schuman Says:

    Editor’s Note: The story does not suggest that PCI should apply to anything beyond payment. But it does acknowledge the reality–a reality that is not a bad thing, actually–that many businesses do use the best practices included in the standard as guidance for a wide range of security practices. The irony we noted was that the PCI Council opted to not be among them.

  13. Dave CISA/M/SP Says:

    The word version of this document only exists so that self-assessors preparing a ROC have a document into which they can enter their data. It’s a tool provided for convenience. It’s not the PCI equivalent of NIST’s meter bar, an item that it is essential it be kept inviolate in a tightly controlled environment to maintain the integrity of the standard.

    Let’s ask the Security Question: What was the RISK here? If a user chooses to hack the password and alter the document, they’re not hurting anyone but themselves. No forensic investigator s going to go by their altered document nor is it likely to stand up in front of a jury. Mom always said, “If you’re fooling yourself, you’re fooling the biggest fool of all”. IMHO the Council made a risk-based decision and chose to secure the document at a level they deemed appropriate. PCI DSS was never in play, either as a standard or a best practice.

    I am advocating focus on REAL issues that matter to this community: lowering the cost and complexity of PCI by treating it as the business problem it is, identifying cost-effective steps for making PCI more accessible to small businesses (who represent the majority of compromises), identifying the impact of compliance-enabling technologies, or the explaining the advantages of getting to validated hardware and software to lower risk.

  14. James Says:

    Irrelevant…no credit card, no PCI, no DSS.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.