July 12, 2007

Airline PCI Violation

Category: Security Information Management — Raffael Marty @ 12:34 am

Today I was booking my airline ticket to Kualalumpur, Malaysia for my trip to Hack in the Box in September. I called the sales lady for the airline and talk to her about my flight dates and all that. In the end she asks me for my credit card information. Number, expiration date, and then the CVV number on the back of my card (the security code, as it is called sometimes too). I hesitate for a second, trying to remember what I just learned from the PCI auditors we had in house. I couldn’t really remember when a merchant needed that number, but after a second I realized that it would be okay to give it to her. It’s about the same as on a Web page, where you enter that information. They can use the CVV to run a authorization with the credit card company. Well, I thought that would be it. Wrong!

A couple of hours later I get a pretty ugly Excel spreadsheet back. I am asked to print it out, sign it, and fax it back to them. I had a look at the form and I wondered what was going on. Well, there was all my information in this spreadsheet, including CVV number! They even “encrypted” my credit card number in the spreadsheet. I am just kidding. It was all in plain text. The only funny thing was that the credit card number field was not formatted as a string, but a number, so it looked like it was encrypted. *grins*. But back to serious. I was quite upset. All my information in this document. I have to assume that this excel document is on the sales person’s desktop, along with probably dozens of others. Hmmm… Maybe I should send an email with a link that points to a site that contains a … Let’s not even go there.

The next thing I did was digging up the PCI standard. And here it was, section 3.2.2:
3.2.2 Do not store the card-validation code (Three-digit or four-digit value printed on the front or back of a payment card (e.g., CVV2 and CVC2 data))
A clear violation! And you know, this is pretty much the first thing you should address; the way of authorizing credit card transactions. Just plain wrong! Darn!

I wrote them an email asking for a contact in their security department. So far, no luck, just the sales person telling me that she needs all that information to complete the transaction. Whatever. Either she needs my signature, but then no CVV, or the CVV and no signature. But not both! I wonder how this is going to continue.

Technorati Tags: , , ,

6 Comments »

  1. Who does one report this sort of incident to?

    Comment by dre — July 13, 2007 @ 5:53 pm

  2. I’m wondering whether it is a violation of PCI DSS. PCI applies to the situation where credit card info is stored or transmitted over internet. In this case, MAYBE the card info is not stored as soft copy (the sales person can type the info into computer, do NOT save it, print it out, then clean all the cache), and it’s not transmitted over internet (transmission is through FAX).

    Comment by HJ — July 20, 2007 @ 12:26 am

  3. […] my flight dates and all that. In the end she asks me for my credit … article continues at Raffael Marty brought to you by travel and […]

    Pingback by   Airline PCI Violation by travel.ZapiZapi.com — July 25, 2007 @ 4:46 am

  4. You’re absolutely correct – the storing of the cardnumber and the CVV is a PCI Standard violation. What’s raised my eyebrow was that they asked you for a signature – any merchant with a MOTO or online CNP account does not require a signature once they have the cardholder’s info. I’d be looking out for a little fraud operation on the side, as there is no reason whatsoever for a signature. Who to report it to? That’s easy enough – if it’s an airline, they’re likely at least a level 1 or 2 merchant, and as such are required to have periodic audits by the card services. Call the company associated with your card, and tell them the problem you encountered, that it was a PCI violation, and you want to report it to the Qualified Security Assessors responsible for auditing that company, or rather to your card service provider preferably. They have gone to great lengths and expense to ensure compliance by all merchants, particularly L1’s & 2’s. I don’t think they’d look kindly at an operation that was so blatantly violating their standard.

    Comment by John R.V. Jones — August 8, 2007 @ 3:18 am

  5. Get yourself a new credit card once a month to prevent the worst. Don’t link your credit card to your primary checking account. Don’t give away cvv.

    Comment by Neon — September 3, 2007 @ 11:21 pm

  6. John R.V. Jones wrote:
    >What’s raised my eyebrow was that they asked you for a
    >signature – any merchant with a MOTO or online CNP
    >account does not require a signature once they have the
    >cardholder’s info.

    Yes the merchant can get an authorization (auth code) from one of the card networks without the cardholder’s signature but the liability for Card Not Present transactions is squarely with the merchant.

    As any experienced Card Not Present (Mail Order/Telephone Order, Internet) merchant knows, such authorizations from the card’s issuing bank are sadly worth the paper they are printed on.

    It sounds like this was a clumsy attempt at an authorization form by the airline. Certainly they should be admonished for the way that they got that ‘form’ to the cardholder, but without an authorization form with signature the merchant is wide open to chargeback risk.

    The card associations need to provide better information to merchants as part of the authorization process and to accelerate liability shift away from the merchant if they want less of this kind of thing going on.

    PCI DSS is important, but it and 3D-Secure and CVV are all band aids on the broader issue of merchant liability.

    Comment by DalPay Thorsten — July 1, 2008 @ 3:10 pm

RSS feed for comments on this post. | TrackBack URI

Leave a comment

XHTML ( You can use these tags): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> .