Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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 6 at 19:29
3  
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 6 at 21:10
    
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 6 at 21:28
1  
you are correct @ivan - I eat crow. I'm blaming that one on a lack of caffeine... –  DKNUCKLES Jun 6 at 22:18
    
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 7 at 11:28

3 Answers 3

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/

share|improve this answer
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 6 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 6 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 6 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 6 at 22:00

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.

share|improve this answer
    
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. –  ub3rst4r Jun 7 at 6:22

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.

share|improve this answer
    
Disclaimer 3: Your web server is still in-scope for PCI compliance. –  Timee Jun 9 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 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 at 17:35
    
The web server can absolutely be in scope, it is entirely dependent on the implementation. See the official guidance: pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/… –  freb Jun 12 at 18:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.