Retailers Fighting To No Longer Store Credit Data 136
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 (Score:5, Funny)
Re: (Score:1)
Wait, you want retailers to store every bit of data they can about you? Have fun with that. Its the other way around in Canada. I don't have to provide any information to a retailer that isn't absolutely necessary for the transaction. I don't want them storing loads of information on me that may or (more likely) may not be stored securely.
Personally, I like the idea that I can just say "No thanks" when some sales person tries to collect my name, address, etc. so I can buy some batteries. The best par
Re: (Score:2)
I have never had to give any personal information.
Re: (Score:1)
Re: (Score:2)
Here in northern BC this isn't a problem. They still haven't figured out how to enter beaver pelts into a computer system.
Re: (Score:1)
You mean like DNA?
Re: (Score:2)
DNA is the security equivalent of dropping postit notes with your PIN's everywhere you go. And fingerprints are the equivalent of gluing a rubber stamp with your PIN to your finger and leaving it on anything you touch. Remember the part about not writing down your password and attaching it to your screen? Putting it in a photocopier, printing five million copies and leaving it everywhere you go can actually be a worse policy than attaching it to your screen.
So, please, dont feed the biom
Data Theft (Score:4, Insightful)
Re:Data Theft (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Re:Data Theft (Score:4, Insightful)
Re:Data Theft (Score:5, Interesting)
"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: (Score:2, Insightful)
Re: (Score:2)
It is essentially as an invisible SSL proxy - decrypting the clients' request, re-encrypting it for the server at the other end and storing what it's decrypted in the middle.
The worst that happens is the user sees an error message from their browser complaining about the certificate. But seeing as 15 years of Windows have encouraged people to ignore error messages, that's not a particularly big deal.
Even this, however, can be avoided. If you con
Re: (Score:2)
Re: (Score:2, Interesting)
In a wa
Re: (Score:2)
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: (Score:1)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:1)
> worse then get the lazy bastards to re-swipe or re-enter the card data.
In the UK there's a move towards ensuring credit card numbers (and other sensitive data) is encrypted, masked, stored securely or not at all.
But the numbers are useful for retailers, for instance when dealing with returns/refunds. Otherwise you have to trust the receipt is valid, assumin
Re: (Score:2)
That's not my experience. The ones I see have the full card number (and are sent one at a time, printed out, by post). If you keep hashes of the card numbers you can then find the transactions from it easily enough.
No one is forcing stores to save the data (Score:2)
These are turnkey systems designed to be operated by non-experts. Naughty naughty code.
Re: (Score:2)
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
Re: (Score:2)
There ARE reasons to store numbers with the current system - and especially there are reasons to store enough to be able to return money. Consider, for example, an event which is cancelled with a few tens of thousands of tickets sold. Are you going to call all of the ticketholders and ask for the card number? What will you do when someone spoofs those calls? What if you receive an order which you believe to be fraudulent (because y
Re: (Score:2)
Six letters for this. B O O H O O (Score:2, Flamebait)
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: (Score:2, Interesting)
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: (Score:2)
Re: (Score:2)
Sure does make a whole lot of sense to screw yourself because of something so infantile as spite.
Re: (Score:2)
HOWEVER, bitching about PCI at this late a date is simply bullshit.
Well (Score:3, Insightful)
Re:Well (Score:5, Insightful)
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: (Score:2)
Re: (Score:1)
Re: (Score:1)
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.
The credit card companies know every item you buy. They have a complete transaction record along with descriptions. You don't want a retailer being in charge of your personal data. The only thing you want us to have is a unique transaction id generated for each credit card debit made. That way if the data gets stolen its worthless without access to the master database at the credit card vendors, and lets face it, if there database is broken into--- we're all boned. This id method will still give good
Re: (Score:1)
DISCLAIMER: I work on POS systems for a major retailer.
Working on POS systems for a major retailer doesn't mean you have any experience with EFT. What processors do you integrate with? What level of card processing do you support? Your statement seems a little uninformed. I do actual EFT development for a POS software company. We are deployed into thousands of stores in over 70 countries around the world.
The credit card companies know every item you buy. They have a complete transaction record along with descriptions.
That is not true. Most authorization requests contain the card information, the amount of the purchase, but not the items. Some processors do require the ti
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
The receipt is an audit trail that can:
1) Verify the card owner is who used it (signature)
2) Keep track of a specific transaction (transaction #)
3) Keep a list of items sold
What else do you need for an audit trail?
Re: (Score:3)
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
Re: (Score:2)
All they need is a foreign key, the unique transaction number. Bank has a DB with transaction number and amount, etc. Merchant has a DB with transaction number amount (for reconcilliation) and other data including what was purchased, where, and when. That way the merchant's database is useless to id thieves.
One of the big rules for any security is to confine the risk. Duplicating the sensitive data and spreading it across many databases AND retaining it in a central DB at the bank is exactly the opposite
All about shifting liability (Score:5, Insightful)
Re: (Score:2)
There are basically 4 actors in a credit card transaction: The customer, the merchant, the bank, and the CC processor/company.
The question is: In the event of CC fraud, who takes the hit? It MUST be one of these actors. In the current system, it is the MERCHANT that takes the hit pretty much all the time. Chargebacks, for example. Say you buy something from a store and decide you don't like it, etc. and decide to do a chargeback on your card. The merchant is fined, so
Re: (Score:2)
If the credit card companies are offering such an onerous deal to the merchants then it seems to me there is a gap in the market for a payment system that does share the liabilities around more fairly.
One would think. But every such scheme has involved shifting the liability to the consumer (since banks won't touch anything that shifts liability to them), so consumers have swiftly rejected such systems. Remember the photos on CCs? That turned out to to cost the banks money, so they stopped doing it.
What is a card number and pin anyway? ... No wonder there is fraud.
Credit cards don't require PINs. As I pointed out earlier, CC processors have no incentive whatsoever to improve credit card fraud. It's a revenue stream for them. They have put forth initiatives (smart card
a quicker method (Score:1)
give me a Linux live CD and access to the keyboard and i could purge them in just a very short time...
Wait what? (Score:4, Funny)
There ya go!
Re: (Score:2)
Re: (Score:2, Funny)
5,10,15,20,25,30,35,40,45,50,55 * * * *
Re: (Score:1)
SQL> truncate table "customer data";
ORA-00600: internal error code, arguments: [12700], [4389808], [163632983], [23], [104892995], [25], [], []
ORA-03113: end-of-file on communication channel
ORA-03114 not connected to ORACLE
ORA-01012 not logged on
Re: (Score:2)
DELETE FROM customer_data should work anywhere.
Amusing: The shell game (Score:2)
Re: (Score:2)
A service for those who don't want to RTFA (Score:3, Funny)
Re: (Score:2)
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 (Score:2)
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: (Score:2, Insightful)
- 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: (Score:2)
why not encrypt? (Score:2)
I wonder why they don't just mandate something along these lines, for now, at least.
Re: (Score:2)
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: (Score:2)
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: (Score:3, Insightful)
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
Re: (Score:2)
And why don't you do that then? A little more effort, but just use a second database but not the regular kind, but an in-memory database [wikipedia.org]. That way the CC data is in a physically separate database and a SQL-injection in your main database can't get the CC data. Also nothing is written to the disc (except poss
Re: (Score:2)
The CFO won't let us yet... there are still apparently some transactions which require the card number and human intervention. They're working on eliminating those.
Re: (Score:2)
Even better would be public key signatures built into the card's smart chip. Merchant presents transaction data to customer's card. Customer authorizes the transaction. Card signs it and returns it to the POS terminal. DONE!
In this schema, CC number means nothing without a signature. Ideally, the card's public key is signed by the CC company to allow an offline transaction to at least verify that the card was legitimately issued. Even better if the CC company periodically makes a revocation list publicall
Re: (Score:2)
Re: (Score:2)
Umm... I did mention "hardware key escrow". Which implies either a smart card or a TPM of some sort.
Yes, and I'm saying that as long as we're passing out smart cards, why not use public key signing of plaintext transactions ( which is VERY different from escrow of s symmetric key!) and make the CC number itself non-sensitive.
Re: (Score:2)
The problem with replacing credit cards with smart cards or something better is the same as the problem with deploying IPv6. Nobody wants to be a first mover, as there's not much value until a significant percentage of everybody else is using the new stuff, too. Clasic chicken and egg problem.
Things like chip-and-PIN can get implemented in Europe by legislative fiat. There's a lot of resistance to that sort of thing on this side of the pond.
Re: (Score:2)
If Visa, Amex, and MC say here's your new card, here's how you use it and BTW, it's immune to identity theft, it WILL happen, and FAST.
Nothing precludes a transitional period where the CC number on the front works just the way it does now. Incentives could reasonably include a better rate for smart-chip transactions (since they carry less risk).
If legislation stopped them cold from trying to collect bad charges without better proof of who made them (a move that could easily be justified), they WOULD do
Re: (Score:2)
Amex actually came out with a smartcard/creditcard combo called, I think, "Bl
Re: (Score:2)
If you convieniantly ignore the part of my suggestion where the card companies are made liable (really where their existing liability is finally recognized or seen from an economic standpoint, internalizing the externalities) I suppose you might have a stronger argument.
As far as amex, you missed the part where I suggested financial incentives. As far as I know, Amex offered none. In fact, if the upgrade costs were to be paid for by the merchants, they offered financial disincentives.
In other words, I h
Re: (Score:2)
IPv4 allocation fees are such a small part of the total cost structure for an ISP that IANA doesn't have any leverage. As IPv4 addresses become scarce, and an after-market develops and prices increase, IANA might gain some of that power. If IANA were to arbitrarily raise fees now, when there is still IPv4 address space available, there would be a major revolt, and another re
Re: (Score:2)
Currently, IANA is holding the price down but making it increasingly difficult to get them to actually allocate IPs. At one time, a justification of "we're setting up an ISP, we need a class B" was good enough. These days they want everything but the results of your last rectal exam for a class C. It might be better if they DID use price as the controling factor since the current system strongly favors encumbants . Unless you ALREADY have a zillion well justified hosts, no IP for YOU! Of course, unless you
Re: (Score:2)
Your bias is showing, AC. Allocating un-swappable memory is very easy in Windows as well, just not in a high-level language like, say PHP. If you want to use C or C++, it's simple. Try at least peeking at MSDN [microsoft.com] before your knee jerks and you say "Windows can't do that".
Several Issues (Score:4, Insightful)
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. (Score:4, Insightful)
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: (Score:2)
Cash is also very dirty (Score:2)
Speaking from experience... (Score:4, Informative)
Re: (Score:2)
I, for one, am glad for the PCI and the demand for a certain lev
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
The standards themselves are a collection of best practices that all make sense individually, but it seem
It's very simple (Score:5, Interesting)
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.
Re: (Score:1)
Re: (Score:2)
True, but they would first spend millions in campaign contributions/political cock sucking in order to ensure that such a law would be so watered down as to be effectively useless.
Re: (Score:2)
Absolutely! The last thing they want is a secure and accountable system where they can be held responsable for their own screwups, or perhaps even worse, a secure system where smaller players can get in on an equal footing and force them to compete.
Bad design rears its ugly head (Score:1)
Hmmm, sound like no data modeling, rushing through the design phase, etc. just to save costs and get the fucktard managers to stop screaming about needing it "yesterday" and other such shit. Excuse me if I don't shed a tear.
It's the POS vendors more than the retailers (Score:2)
Worse than that! (Score:2, Interesting)
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
Re: (Score:2)
I don't understand... (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
1. Who do you think Blizzard gets the money from to cover these costs? (Clue: It is not the tooth fairy).
2. Follow the money. Large retailers have lots of money, which means they can afford to should loudly "We don't see why we should be liable for this". Banks have even more money, so they can shout even more loudly.
Customers have the least money.
Who do you think they want to hold liable? (Clue: Look at who's liable for card fraud in the UK now we have Chip & PIN).
What disruptions? (Score:2)
You mean that suddenly I won't be receiving junk mail, spam and telemarketing calls?
I'm all for it.
Agencies and bullshit (Score:2, Interesting)
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
There are a few issues with PCI (Score:2)
The 2nd issue is that the PCI auditors are foolish enough to be set up to take the blame and provide insurance when a company fails. Lets assume that a processors gets hacked and is sending card numbers off to mob in a different country. How do banks cover reissuing the cards and recovering anything they don't stick the merchants with? In this case the processor that is