42

I'm overhauling our absolute time-bomb of an order processing system that would put us out of business tomorrow were we audited for PCI compliance. It's so amateur it's scary.

I'm planning on making a case to the higher-ups that the liabilities of storing CC information outweigh the conveniences of not having to re-ask the customer for numbers, but I know I'm going to get asked how vendors like Amazon and such get away with storing information for repeat purchases, and I have no answer to this.

So, how do vendors like Amazon and everybody else who bills monthly authorize future charges without storing things like CVV info, which is expressly forbidden by PCI DSS v3?

I read elsewhere that tokens can be created and stored in lieu of stripe info, but isn't possession of a token representing the contents of the stripe just as valuable as the stripe info itself? Anybody with possession of the token could make fraudulent charges, so who cares whether they have that or the actual CC/CVV info?

Or is token conversion just a way of saying "we're not storing the actual PAN/CVV" and passing along regulatory compliance issues to whoever issued it?

Ivan
  • 6,288
  • 3
  • 18
  • 22
  • Have you read through the PCI DSS guidelines? From my understanding (and it's been a while since I've had to read the guidelines) you cannot store the PAN in it's entirety in cleartext. Assuming this is the case, a salted hash *should* fit the bill. – DKNUCKLES Jun 06 '14 at 19:29
  • 8
    A coworker of mine used to work with Amazon. He described their system to me once, and trust me, your company does not want to use Amazon as a model of how you should do credit card processing, at least not unless you have the resources of a company like Amazon! The server that holds the CC information is *literally locked in a vault*, and that's just the beginning of their security. – Mason Wheeler Jun 06 '14 at 21:10
  • 2
    DKNUCKLES - My interpretation is that it is acceptable to store a hash of a PAN, but my understanding of hashing is that it's a one-way operation. If we can't un-hash the card number in order to use it again, I don't see the point in storing it in the first place (as opposed to a reference number)... Mason - Very interesting, thanks. And yes, part of my reasoning for not wanting to house CC data is that we don't have the resources of such entities. I'm just one guy! – Ivan Jun 06 '14 at 21:28
  • 1
    you are correct @ivan - I eat crow. I'm blaming that one on a lack of caffeine... – DKNUCKLES Jun 06 '14 at 22:18
  • 1
    Go with tokens. 1) If CC info never hits the server, you don't need to bother with PCI 2) A token can be invalidated without much collateral damage. Compare with sending a replacement CC to all users. 3) It's usually bound to a certain merchant's account, so a leak of your DB doesn't allow the attacker to send the money to their account. In contrast a CC number can be used with any destination account. – CodesInChaos Jun 07 '14 at 11:28
  • @ivan Hashing is only one way if the input space is big enough for guess-and-confirm to be infeasible. CC numbers are short and guessable. – CodesInChaos Jun 07 '14 at 11:29
  • Shameless plug, related [How does Amazon bill me without the CVV](http://security.stackexchange.com/questions/21168/how-does-amazon-bill-me-without-the-cvc-cvv-cvv2) -- in short, you only actually need the card number to charge it. – TC1 Jun 07 '14 at 20:28
  • tokens are great until your primary gateway goes down, then you need to get the card detail again from your customer... large ecom sites have this issue all the time... #sigh – Dawesi Jan 26 '17 at 11:20

4 Answers4

34

Ivan, this is an absolutely huge topic. And you have a bunch of questions here. I'll try to help but this will likely be closed as too broad.

I'm planning on making a case to the higher-ups that the liabilities of storing CC information outweigh the conveniences of not having to re-ask the customer for numbers, but I know I'm going to get asked how vendors like Amazon and such get away with storing information for repeat purchases, and I have no answer to this.

It's perfectly acceptable to store credit card data, but there are a ton of rules surrounding how you do it - where, how, auditing, etc. There are a lot of books on this subject.

So, how do vendors like Amazon and everybody else who bills monthly authorize future charges without storing things like CVV info, which is expressly forbidden by PCI DSS v3?

You don't need to have the CVV info at all, it just helps with fraud. After checking it the first time (which can be done without writing it to disk) you can assume the card is not fraudulent. It has done the job it needed to do.

I read elsewhere that tokens can be created and stored in lieu of stripe info, but isn't possession of a token representing the contents of the stripe just as valuable as the stripe info itself? Anybody with possession of the token could make fraudulent charges, so who cares whether they have that or the actual CC/CVV info?

Tokenization is good if you manage to get the cardholder information out of your environment and into someone else's care. The 'token' is a unique identifier that allows your system to still act in the traditional sense. You provide a list of tokens to your provider and they translate them into the real numbers.

This is good because it is their responsibility to store / process / etc the real numbers. Your liability disappears in this regard.

Or is token conversion just a way of saying "we're not storing the actual PAN/CVV" and passing along regulatory compliance issues to whoever issued it?

Exactly, except it's to whomever processes it, not who generates the tokens. :)

Edit: a lot of businesses don't take interest without understanding the cost of non compliance.

See http://www.pcistandard.com/card-association-fines/

Tim Brigham
  • 3,762
  • 3
  • 29
  • 35
  • 1
    Good comments. Of course, you *can* process the data yourself and still get some of these benefits by offloading the actual card processing to a sub-system that has the best security available. This is what some (maybe all?) large banks do. – Julian Knight Jun 06 '14 at 19:31
  • @JulianKnight - true. We use a method very similar in house. I didn't want to confuse the matter with the 'they' possibly being a dedicated team in the office.. That's a whole ball of wax on its own. – Tim Brigham Jun 06 '14 at 19:57
  • 1
    Very interesting; thanks, Tim. As it stands we just don't have the resources (or the business need, frankly) to safely store consumer data in-house, and PCI compliance is only going to be a topic of concern as long as I'm employed here and making noise about it. At least if the higher-ups tell me to carry this feature forward I can try to work out something better than storing names and PAN numbers in plaintext tables! I'll see what our processor can do. Thanks again! – Ivan Jun 06 '14 at 21:53
  • 1
    @Ivan - a lot of businesses aren't interested until they see how stiff the peanalties are. See edit. – Tim Brigham Jun 06 '14 at 22:00
  • Hi @TimBrigham could you elaborate on the sentence "except it's to whomever processes it, not who generates the tokens" ? What do you mean precisely by "process" ? Do you mean that we could for instance send data along with a token of our own (generated around a uuid) so whoever "generates" (issue) the token value (the string) is not a matter ? – niahoo Jul 03 '20 at 16:22
  • @niahoo, the idea is that the provider - paypal, whomever - generates a token and does all the handling - and gives you a token that you can reference internally instead of using the actual credit card number. You shouldn't ever know what the token represents. – Tim Brigham Jul 08 '20 at 14:23
  • @TimBrigham so in that example and with your words it is Paypal that "processes" the token, right ? (because they do some actual work with the data related to the token) – niahoo Jul 08 '20 at 17:14
7

It's been a few years, but when I was doing ecommerce (including one job for a large company that had previously been storing thousands of credit card numbers in plaintext), my preferred method was using Authorize.net's CIM service (other providers have similar services, that's just the one that I'm most familiar with; shop around for the one that works best for you).

The way that it worked was that you sent the info to the processor and they returned a token. The token is safer than the actual card data because it is only good to charge that card to your account using that one processor. Someone couldn't take the token and use it elsewhere, and if they did get it, all they could do with it would be to make bogus charges from you, which would put money in your account and make you look bad, but you could refund the money and cancel the tokens and no real harm done except temporary inconvenience - no money lost to the bad guys and no need to replace the card.

If the recurring charges are consistent and scheduled, some other card processing services let you set up subscription plans, where you initially send the card info along with a plan description of how often to bill how much. Thereafter, you can cancel the plan, but you don't have either the card info nor a token, so you can't accidentally charge them (as you could with a token) or lose their card info in a breach.

Never ever store CVV in any way, that is strictly forbidden. You don't need it at all, and having it is a huge liability. You should not need to store anything except at most a token or subscription id. The last 4 digits and card type (visa/mastercard/etc) may help customer service, but not really necessary.

RSTaylor
  • 71
  • 1
  • Stripe also does this. They create a token that can be used to do recurring charges to a credit card and you don't have to worry about storing credit card numbers yourself. – SameOldNick Jun 07 '14 at 06:22
  • tokens are only useful for smaller transactions... gateways go down, and your secondary gateway can't access the persons details using the token from provider 1, so it comes down to that also. Tokens are the best 'quick and dirty' way to to this. – Dawesi Jan 26 '17 at 11:21
2

RSTaylor is pointing you in the right direction. There are companies who will provide credit card processing for you (for a fee, of course). You can build a site so that the customer's number never goes to your servers, not even in RAM, so it can't be compromised there.

Disclaimer 1: You'll have to rely on the integrity and compliance of that company. I don't know enough to suggest a specific company.

Disclaimer 2: It is also somewhat tricky to get the credit card function seamlessly into your site, but it can be done.

O. Meyer
  • 21
  • 1
  • Disclaimer 3: Your web server is still in-scope for PCI compliance. – Timee Jun 09 '14 at 15:48
  • @Timee's disclaimer is just plain wrong. If the cardholder information isn't in RAM at some point it wasn't transmitted to the server in question. If a server doesn't transmit, store or process cardholder data it isn't in scope. – Tim Brigham Jun 12 '14 at 15:07
  • Read the new scoping guidelines for PCI DSS 3.0. if a system can influence the integrity of card data then it is considered in scope for PCI compliance and must meet the requirements. Here is a direct quote from PCI DSS 3.0: "To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE." With the type of payment configuration described a compromise to the webserver could impact the CDE and card data. – Timee Jun 12 '14 at 17:35
  • 1
    The web server can absolutely be in scope, it is entirely dependent on the implementation. See the official guidance: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-there-a-different-approach-for-Direct-Post-implementations-than-for-iFrame-and-URL-redirect-what-are-the-technical-differences-and-how-do-they-impact-the-security-of-e-commerce-transactions/?q=web+page&l=en_US&fs=RelatedArticle – freb Jun 12 '14 at 18:01
  • This this this this this. Freb also has the right of it (or stated alternately, Tim Brigham and Timee are both right). – Smithers Dec 26 '14 at 19:06
0

For your question

So, how do vendors like Amazon and everybody else who bills monthly authorize future charges without storing things like CVV info, which is expressly forbidden by PCI DSS v3?

I want to give an exact scenario about it.

  1. I buy a book from Amazon via my Kindle with one click payment process but the payment fails. I am sure I have enough credit on my credit card and I always shop with the same card at Amazon.
  2. When I check the order details it says there is problem in the payment process, and asks me to please use another card.
  3. When I check the card and bank information I realize my bank has a fraud check because it stolen some card data and CVV is required for all online payments.

So it means it is about a fraud rule between the merchant and the bank.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
erhun
  • 101
  • 2