Retailers Fighting To No Longer Store Credit Data

Technical Writing Geek writes with the news that the retail industry is getting mighty fed up over credit card company policies requiring them to store payment data. The National Retail Federation (NRF) has gone to bat for store owners, asking the credit industry to change their policies. The frustration stems from payment card industry (PCI) standards and new security measures going into place across the retail experience. Retailers are now trying to point out that many of the elements of the standard would not be a requirement if they didn't have to store so much payment data. "Even if the NRF's demands were immediately met, it would take several years before retailers could purge their systems and applications of credit card data, he said. Over the years, retailers have collected and stored credit card data in myriad systems and places -- including relatively old legacy environments -- and they are just now realizing the data can be a challenge, he said. Purging it can be a bigger headache because the data is often inextricably linked to and used by a variety of customer and marketing applications; simply removing it could cause huge disruptions."

While were at it

[by Anonymous Coward]

Let's ditch social security numbers too. Once we purge everything, we can come up with a new, unique, impervious to fraud, uncrackable new id for each person and their various accounts.

Re:

[geekoid (135745)]

That's no different then in the US.

I have never had to give any personal information.

Re:

[belmolis (702863)]

Here in northern BC this isn't a problem. They still haven't figured out how to enter beaver pelts into a computer system.

Data Theft

[KGIII (973947)]

And if they didn't store the data then we wouldn't have the TJ Maxx crap like stuff going on in the first place. Storing it should be illegal - encrypted or not. There is no reason that numbers need to be stored - even for subscriptions. If worse comes to worse then get the lazy bastards to re-swipe or re-enter the card data.

Re:Data Theft

[CastrTroy (595695)]

I had a professor in univesity for one of my security classes. Basically, he told us that SSL, while it's good at what it does, doesn't really solve the real security issues with transactions happening over the internet. Nobody sniffs the wire or does man in the middle attacks to collect the data, because it's often very difficult, and requires physical access to cables. What they usually do is just break into the back end database that's storing all this data. It's much easier. Him and some of his colleagues came up with a much better system, whereby the credit card info never went to the retailer, but instead just a digital certificate signed by the credit card company that would authorize a payment for some certain amount. In the end, the industry decided not to go with that standard, because it was harder to implement. It solved the real problem, but SSL was adopted because they figured it was good enough. It's interesting to see that decision coming back when if they would have just done it right the first time, we'd have much less problems.

Re:

[wbren (682133)]

Cardspace [netfx3.com] could do something similar, in theory. You might want to look into that. Even though it's from Microsoft, it is pretty cool and surprisingly open.

Re:

[qbwiz (87077)]

Paypal seems to be doing just that. Now, we just have the problem of trusting Paypal's servers.

Re:Data Theft

[heckler95 (1140369)]

I would much rather trust PayPal's servers than every little Mom & Pop business with an e-commerce website that they hired the local high school wiz-kid to create on $4/month shared hosting. N.B. I used to be that wiz-kid.

Re:Data Theft

[geekoid (135745)]

That professor needs to get with the times:
"Nobody sniffs the wire or does man in the middle attacks to collect the data, because it's often very difficult, and requires physical access to cables."

No, usually a bot is placed in a router that does it for you. There is very little need to be physically at the wire it most cases, anymore.

OTOH, since his 'better method' was only better under the fallacy that no one watches the line.
As someone who has written sniffer to ferret out unauthorized movement of SSN within an organization, I can honestly say that I never physically went to any router or box to do the install.

Actually, now that I am thinking about it(it's been 10 years) I didn't physically go to one location.

I took a switch/router that I installed the bot on and physically unpluged a network cable, plugged it into this router and then plug a cable from the router to the port. No one monitoring the network noticed anything. It took me about 4 seconds to add the switch.

That was done on a bet.

Re:

[maxume (22995)]

So the traffic you were sniffing was SSL encrypted?

Re:

[VTI9600 (1143169)]

I'm sure your professor's solution was quite elegant, but I must point out that this is completely unnecessary in practical applications since most payment gateways support a method of integration where the credit card data is never passed to the merchant. AuthorizeNet's Simple Integration Method (SIM) is one example of this. The customer is either redirected to the payment gateway's website (SSL encrypted) or the site is presented in an IFRAME. The gateway then sends the result back to the merchant.

In a wa

Re:

[geekoid (135745)]

Credit card companies are not banks.

If the gateways are secure, then the CC company can do the EXACT SAME THING to protect there networks.
The third party company is not needed.

Classic error, move the problem around, and call it solved when in fact the same problem is still there. The only way this could work is if the third party has magic 'anti-compromising' abilities not available to any one else.

Re:

[TemporalBeing (803363)]

Basically, he told us that SSL, while it's good at what it does, doesn't really solve the real security issues with transactions happening over the internet. Nobody sniffs the wire or does man in the middle attacks to collect the data, because it's often very difficult, and requires physical access to cables.

Well, SSL encrypts the data in transit. Regardless of whether one thinks the lines are being sniffed or not, it's still a good idea to do so. Also, since it goes over public infrastructure (at least f

Re:

[Todd Knarr (15451)]

Now compare that to Digitally Signed - you have a public key that gets distributed for verification, and you sign the private key. The set stays constant - you keep the private key, but you pass around the public key in plain text. So then, someone can get a hold of your public key and derive the private key. Once they have done that, you are compromised as they can then pretend to be you.

The trick is in the "derives the private key" part. In a public-key system, doing that involves factoring a very larg

No one is forcing stores to save the data

[wsanders (114993)]

The standards don't make the companies save the data. On the contrary, they PROHIBIT saving the data. The problem is that a lot of PCI systems save the data by default, and merchants either can't figure out how to stop it, or try to stop it but the software saves it anyway. Few of the vendors getting vendors getting caught deliberately save it for their own convenience.

These are turnkey systems designed to be operated by non-experts. Naughty naughty code.

Re:

[Midnight Thunder (17205)]

And if they didn't store the data then we wouldn't have the TJ Maxx crap like stuff going on in the first place. Storing it should be illegal - encrypted or not. There is no reason that numbers need to be stored - even for subscriptions. If worse comes to worse then get the lazy bastards to re-swipe or re-enter the card data.

Since it is the credit card companies that do the final validation of the credit card, and store the data anyhow, surely they can send back a unique confirmation ID. It would be the cre

Six letters for this. B O O H O O

[Chas (5144)]

I say "tough".

PCI has been coming for a while now.

Why are these people "only now" realizing what this entails?

Oh yeah. Because they ignored it until they couldn't ignore it anymore.

Now they're bitching about how HARD it's going to be to implement or retrofit?

Boo fucking hoo.

They had the opportunity to ammortize the cost out over a longer period of time. Now they get bit because they tripped over a dollar to save a dime.

Re:

[by Anonymous Coward]

Why are these people "only now" realizing what this entails?

Oh yeah. Because they ignored it until they couldn't ignore it anymore.


Because the standard attempts to cover a widely disparate set of industries which have wildly different requirements, from Internet Ecommerce sites to the cashier at Ross.

Details of the standard are often in the eyes of the auditor. Auditor A may have one opinion, and you pass. Auditor B has a different opinion, and then you fail.

The standard is hopelessly vague when it comes to

Re:

[alan_dershowitz (586542)]

That's a bunch of bull. Companies aren't fighting back because the standards are vague and they can't pass auditing. Most of the auditing is automated security scanning and a lot of the rest is a self-audit for which you provide the answers. Companies are fighting back because they don't want to spend the time or money changing their systems. To make them more secure. Or secure at all. Yeah, the standards are terribly vague, but it's basically just a CYA for the credit card company when you lose customer da

Re:

[apparently (756613)]

While you're smugly sitting there with your "I say tough" bullshit posturing, realize that retailers not having to store your CC info, would benefit you.

Sure does make a whole lot of sense to screw yourself because of something so infantile as spite.

Well

[morgan_greywolf (835522)]

It would seem to me that retailers SHOULD be storing the credit card data because there has to be some type of audit trail available. After all, people need to be able to track down credit card fraud, etc. I'm guessing that the credit card companies store this data as well, though, but they probably only store the amount of the transaction, card number and date, whereas the retailers would have the records of what was purchased, on what date, who rang up the transaction, etc.

Re:Well

[MortimerV (896247)]

Why should the credit card data have to be stored by both the retailer and the CC company?

Let the CC company keep a transaction ID and all confidential information, and the retailer keeps the same transaction ID, along with purchase details. That puts the burden of security all in one place, with the CC company, rather than scattered around with all the various retailers.

And if there's a trail to be followed, the CC company and retailer can compare records through the transaction ID.

Re:

[alan_dershowitz (586542)]

Credit card companies do provide such a number. If you don't have to do multiple transactions on the card, you don't have to store the actual card number after it's used. The problem is that companies want to have their cake and eat it too, store the card for repeated transactions or customer convenience, but they don't want to change their systems to store them securely.

Re:

[ray-auch (454705)]

Card companies stored the card account data, retailers store the purchase data. An authentication code for the transaction can tie the two together for audit purposes - no need for retailers to store the card data.

In fact the only reason I can see for a retailer storing the card data is to make another transaction without having the card (or re-entering the data). As a customer that is precisely why I _don't_ want them storing card data. The only benefit to a customer is online, saving a few seconds typ

All about shifting liability

[gclef (96311)]

I would be *very* surprised if the banks voluntarily accepted liability for any part of this chain. They face none now...they'll need a very strong reason to take any risk. The banks like the present system because they face no liability...if the merchant didn't do the right thing, or faces a chargeback, it's all on the merchant. (and it's on the merchant for liability if they're hacked)

Wait what?

[techpawn (969834)]

several years before retailers could purge their systems and applications of credit card data

TRUNCATE TABLE Customer Data

There ya go!

Re:

[Connie_Lingus (317691)]

Yeah..but what happens to all the "INSERT INTO CUSTOMER_DATA" calls sprinkled all over the 20 year old legacy spaghetti code?

Re:

[jmyers (208878)]

"Yeah..but what happens to all the "INSERT INTO CUSTOMER_DATA" calls sprinkled all over the 20 year old legacy spaghetti code?"

5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/purgeCustomer_Data.pl

Amusing: The shell game

[Bomarc (306716)]

This has nothing to do w/ storing 1's and 0's. It has everything to do with your credit score. If they don't have the information, you can't fight it. If they have any information it must be secured, so why are they bitching and wining about the amount of data? Look behind the question to see the real answer.

Re:

[superpulpsicle (533373)]

Even the definition of "secure" is always up for questioning. Who is to say it is secure?

A service for those who don't want to RTFA

[pushing-robot (1037830)]

"Retailers: In the interest of preserving your privacy, we'll all put your information into a single database instead of scattering it among lots of little ones."

Re:

[dctoastman (995251)]

You do realize that the CC companies already have this data. It is not a choice of scattered or centralized, it is a choice of just centralized or scattered and centralized.

And honestly, I'd prefer the just centralized model. I'd rather not have to worry if Amazon, WalMart, TeleCheck, etc. were all on the ball in regards to security in addition to Chase, Capital One, etc.

The joys of insecurity

[Y-Crate (540566)]

Keeping them must be a pain, but securing them should be an easy thing to accomplish. Sadly, it's not something that every store takes great pains to do.

At the major book chain I used to work at, the unlocked stockroom had a shelf filled with boxes marked "CC Recepits X" where 'X' was the date range.

If you walked out with something like two boxes, you could theoretically have the information for every customer that payed with a credit card over the course of a year.

Then again, shrink was a huge problem, and

Re:

[SoCalEd (842421)]

Its not that easy and its not just at the store itself. I work for a large national retailer and sit on the committee that is overseeing implementation of the CISP and now PCI requirements. Anti-intrusion systems and other general network security issues aside, there are, unfortunately, a lot of touchpoints that make this hard, time consuming and costly.

- Not all point of sale systems (especially older ones) are set up to only show last four = code modification. If the vendor still supports it.

Re:

[CastrTroy (595695)]

If it's something that's easy to accomplish, then they should have to take great pains to do it. The fact of the matter is, is that it is hard to do, especially when your employees aren't security engineers, but rather people with absolutely no training in how to keep this data secure.

why not encrypt?

[Connie_Lingus (317691)]

As a side job simply to learn PHP, I built a E-Commerce site using osCommerce, and was shocked to find that they stored the customer CC in plain text in a table. After dealing the the 30 other issues osC has, I grabbed a OS PHP encrypt class from somewhere and added 512-bit encryption to the CC number and stored it like that.

I wonder why they don't just mandate something along these lines, for now, at least.

Re:

[Minupla (62455)]

Thats part of the mandate of PCI compliance. Problem is, encryption is easy, key managment is hard. Where do you store the keys, who gets access to them? How do you know they're going to do the right thing with them? Who audits these processes? How do you know the encryption process is secure? How do you make sure it stays that way after deployment?

Encrypt it is an easy answer, but it spawns a lot of harder to answer questions, especially for a smaller company without a security devision, compliance d

Re:

[Connie_Lingus (317691)]

Right, but a big push behind PCI was to get the CC info off of insecure servers/databases because, in general, the CC companies are mostly worried that individuals are going to hack into poorly-secured e-commerce sites and download tables loaded with CC data.

As you said, encrypt is easy, and in these cases (a third-party hack into an admin account), encrypt would prevent the thieves for getting access to their primary target, the list of CC numbers. It's a easy answer to 80% of the problems, and with such

Re:

[Thundersnatch (671481)]

You're missing the point. The encryption doesn't prevent anything in 90% of applications, because the key mangement is terrible. You might was well just use base64 encoding and save the CPU cycles. Just using an AES-256 library function doesn't make the data secure.

Most applications I've seen - quite a few, both in-house and off-the-shelf - use a fixed symmetric key for credit card encryption, stored right in the application code or in a configuration file. Often this key is on the same server as the databa

Several Issues

[wardred (602136)]

There are at least two issues with credit card data based on this article. I definitely like the retailer's NOT storing full credit card data. The credit card type, possibly the bank, the card holder's name, the last few digits of the credit card number, and the charge date and time should be more than enough to identify a transaction, especially if there's a transaction id. The credit card companies HAVE to have full account data, but the more systems this data is stored in, the less secure it is, no matter what security is implemented at each individual site. If you can remove the bank and CC number entirely and work strictly off of transaction ID and card type, I'd be even happier. Storing this minimum of data would allow everybody to identify a particular charge if there's a dispute about charges, would still allow retailers to generate whatever statistical data they need, and would prevent identity thieves from getting full CC numbers, expiration dates, etc. from retailers.

On the other hand, retailers still need to secure whatever legacy data they have, and work on purging the systems that store it. These are two different problems, and both sides of this debate seem to want to point out the problems with their opponent's positions without addressing their own issues. If retailers have the data and aren't securing it, then I have little sympathy for them when they get heavily fined for not treating our sensitive data properly, even if the CC companies require the storage of some of that data and shouldn't. Especially for major retailers where the IT budget can be spread across many, many stores.

So, short term solution is to get the retail stores to abide by the current security regulations posted by CC companies. The longer term solution is to get a more sane set of security solutions from the CC companies, and make it so that every retail outlet is required NOT to store sensitive data that crackers might want to get a hold of. This would reduce the number of outlets to our sensitive data to a minimum. It would reduce it to the companies that have to retain that data anyway.

Cash is so easy.

[miracle69 (34841)]

"This note is legal tender for all debts public and private."

Very simple compared to the 15 page credit card contract for the consumer and the headaches for the retailer.

Henry David Thoreau said it best, "Simplify".

Re:

[CastrTroy (595695)]

Cash comes with it's own pitfalls. First paying for purchases over the internet is quite difficult with cash. It's not something you can send over the internet, and not something you want to send in the mail. Also, credit cards have other perks, like chargebacks, extended warranties, and may other amenities. Provided you pay your card off at the end of every month, it actually make more sense to use a credit card than cash.

Speaking from experience...

[MattyMatt (57008)]

I've been working with a PCI certified auditor for close to nine months now to bring my company into compliance with the latest Data Security Standard. The DSS is a great source if you're looking for a concise primer on good development, administration and training practices, but... Bringing a company into compliance with all the requirements is incredibly difficult. No exaggeration, we've spent tens of thousands of dollars on the audit itself, tens of thousands more on infrastructure and the equivalent of one full time employee working on nothing but DSS compliance for the past year. Once we receive the stamp of compliance from the Payment Card Industry, we just have to turn around and do it all over again next year, the following year, the year after that, etc... Granted, once we get through the first audit, the following audits will be less expensive from a time and money perspective, but we're still looking at anywhere from ten to fifty grand a year for the certified auditor and any DSS mandated changes to our system. For example, the DSS requires for 2008 either an application layer firewall in front of web-facing apps or third-party code review. There goes my bonus for next year... Long story short - very few companies are going to be able to meet the Payment Card Industry Data Security Standard and on top of that, most companies don't want to store freakin' payment card anyway.

Re:

[imag0 (605684)]

A lot of companies (perhaps like yours, perhaps not) are looking into service providers who sweat the particulars of the PCI. That's my job. I have had 3 PCI audits this year, one SAS 70, and another misc bank audit all within the first 6 months of this year. It's a long, and mostly thankless job, but it really feels good to get an excited email from one of my clients letting me know that they passed the ROC and are good to go for another year.

I, for one, am glad for the PCI and the demand for a certain lev

It's very simple

[sjames (1099)]

In spite of the smokescreen being thrown up by the big credit cards, it's really very simple.

The banks ALREADY have and must keep all of the information. Their byzantine PCI standards demand that the merchants keep a full duplicate of this highly sensitive data and dictate how it must be stored. The merchants maintain (correctly) that if the banks had as much intelligence as a slug all they would need to retain is non-sensitive (and useless to identity thieves) transaction/approval numbers rather than very sensitive cc numbers and identifying info.

In other words, in spite of what the banks claim, this is about reducing the risks and liabilities rather than shifting them. In fact, it's the banks that are trying to spread liability by maintaining a situation where they can plausibly play the blame game.

Various schemes have been available for DECADES to make sure that fraudulant credit transactions can not happen but the banks have fought against them tooth and nail in order to keep the current approach where name and cc number are all that's needed to commit fraud. They're also the ones that have been routinely offering big limit credit cards to toddlers, dogs, and cats then trying to stick innocent 3rd parties with the liabilities.

The entire identity theft problem only exists because of the very same banks. I'll bet that it would all stop instantly if a law was passed banning any attempt at collections for credit card debt unless the bank can present a picture of the alleged debtor actually signing the agreement for the account AND that without a digital transaction signature, the cardholder is presumed NOT to be liable for the charge. You can be assured that credit cards with useful smart chips and public key signature capability would be implemented the INSTANT such a law went into effect.

Please feel free to visualise (or not!) an analogy involving identity thieves, defrauded individuals, bank managers and goatse.

It's the POS vendors more than the retailers

[Guysmiley777 (880063)]

When I supported POS systems five years ago I was amazed at what they would store in plain text in log files. Not just CC numbers but the entire contents of the magnetic strip. And POS software is a very stagnant industry, once retailers have a system that works they're very slow to change. Hell, I know of one convenience store chain that is still running Windows 95 with a WinNT back of house.

Worse than that!

[by Anonymous Coward]

Hell, I know of one convenience store chain that is still running Windows 95 with a WinNT back of house.

Hell, I still support a POS system for a fairly large chain of dry cleaning shops that only runs on MS/DOS and uses a Lantastic peer-to-peer LAN in each store, and each store talks to the main office via LapLink and dialup modems each night to transfer it's daily sales data.

I was having hell locating motherboards that still had ISA card slots for the old Lantastic nics and dual RS-232 serial cards (each

I don't understand...

[cdrguru (88047)]

How is a credit card number "sensitive" information in any way whatsoever? You follow the average credit-using American and you will find a trail of credit card number spread far and wide.

For the period 1950-1990 this wasn't really a problem. Now suddenly it is a problem? How? I reguarly have fraudulent charges put on a credit card. At least once a year. Want to know how much this "identity theft" costs me?

Nothing. Ever. Never has. Never will.

Last time around Blizzard got stuck for some chargebacks

What disruptions?

[ScrewMaster (602015)]

... simply removing it could cause huge disruptions.

You mean that suddenly I won't be receiving junk mail, spam and telemarketing calls?

I'm all for it.

Agencies and bullshit

[by Anonymous Coward]

I have to post this anonymously, because I certainly don't want it to ever come back to bite my client, and also this requires me to be vague and my story somewhat hard to read. So here goes.

We have some software that tracks a certain kind of data. There is really no reason whatsoever that social security numbers should be part of this data. However, certain "upstream" entities, whom my client's customers depend on accepting my client's reports for "accreditation" purposes started requiring social security