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."

Comments

While were at it

[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:While were at it

[Nos.]

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 part is, they cannot refuse service if I refuse to provide the information.

http://en.wikipedia.org/wiki/PIPEDA

Re:While were at it

[geekoid]

That's no different then in the US.

I have never had to give any personal information.

Re:While were at it

[belmolis]

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:While were at it

[Nos.]

Read up on PIPEDA, there's a lot more in there that companies south of the border don't have to adhere to. Heck, when we go looking for vendors for various servers, if they're going to host, we have to make sure their data center is in Canada, partially because of PIPEDA, and partially because of the PATRIOT Act.

Re:While were at it

[suitepotato]

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.

You mean like DNA?

Re:While were at it

[Znork]

"You mean like DNA?"

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 biometric 'security' fraud. Or at least use some actual biometric you dont leave everywhere (like, for example, the allusion in Futurama to banks using a colonic map as ID for a period). For people who dont like shoving sensors where the sun dont shine for every authentication they do, biometrics just Aint It. (And even things you dont leave around everywhere will eventually leak from databases, making their persistence and unchangeability the thing that makes them useless).

Re:While were at it

[rk075002]

Excellent idea.you got my support

Re:While were at it

[rinaazlin]

Sure don't forget to announce the password of your account too.

Data Theft

[KGIII]

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]

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:Data Theft

[wbren]

Cardspace 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:Data Theft

[qbwiz]

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

Re:Data Theft

[geekoid]

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:Data Theft

[VTI9600]

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 way this is actually more secure than your professor's solution since it does not require the credit card company (read: banks) payment network to be exposed to retailers' systems, but instead, just a handful of companies specializing in card processing who are subject to very strict security standards (the gateways).

Re:Data Theft

[heckler95]

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]

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:Data Theft

[shofutex]

Perhaps like SET?

Re:Data Theft

[TemporalBeing]

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 for on-line merchants), it is like saying "telnet is good enough because no one sniffs packets". Problem is they do, and it isn't. Encryption is necessary.

What they usually do is just break into the back end database that's storing all this data. It's much easier.

There is some truth to this, but it really depends on the people cracking in. In reality, it is not so much that it is easier to get a single person's account information as it is easier to hundreds, thousands, or millions of accounts and the related information. Why go for one when we you get get two? or two when you get 100? or 100 when you can get 1000? etc.

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.

That is basically PKI system, which is very difficult and fragile. Additionally, you're still sending stuff in plain text, and using keys that have to stay the same all the time in order to be relied on, thus they are crackable. In the end, what happens when someone cracks the companies key and then uses it to buy stuff themselves? All of a sudden the company needs a new key - only they might not know about it for a while as it would appear to be a legit key and in the end they would lose a lot more money than if they went with encryption.

It solved the real problem, but SSL was adopted because they figured it was good enough.

Problem is, as I just explained, it didn't solve the problem. In fact, it would have created a worse problem. SSL uses two sets of keys - the first is dynamically created, and the second is pretty constant. However, the second key is used to seed the creation of the first set. Thus every connection has a relatively unique key set and would need to be hacked on its own, which is why SSL is pretty secure. (For more info look into Diffie Hellman Key Exchange and similar algorithms.)

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 only requirement for the cracker is that they have a fast enough method of deriving the key set that you cannot replace it fast enough, which as computing gets faster - and as Quantum computing comes into play - will only get easier for the cracker.

The credit company would then have two issues: (a) liability for fraudulently signed purchases, and (b) replacing all the keys in the hands of their retail customers. Using SSL makes both pretty irrelevant, which means less liability, which means better business, and better business security.

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.

It's not coming back to bite them in any way. It's a matter of their back-end systems not being well protected, which would have been an issue either way.

Re:Data Theft

[maxume]

So the traffic you were sniffing was SSL encrypted?

Re:Data Theft

[Threni]

> 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.

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, assuming they have a receipt. If they have no receipt and claim to have paid by credit card, what do you do? Just trust them?

Re:Data Theft

[Midnight Thunder]

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 credit card companies who would hold on the transaction data and the stores would store the corresponding confirmation ID. With this approach if the store needs to confirm a transaction, that simply specify the unique confirmation ID. Any extra functionality added to the credit-card would be transparent to the shops since they already have the unique conformation ID. I am thinking of a format like:

    --

Of course anything beyond the credit card company id would be up to the credit card company and all the stores needs to know is that they are storing alphanumeric confirmation strings. On the credit card company side they can hold all the information they want, such as store, card number, date, amount, status, etc. Since the unique confirmation ID does not contain the credit card number it is useless to anyone but the credit card company.

Re:Data Theft

[Todd Knarr]

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 large number. Large as in the product of two 1024-bit primes, which is over a million bits. 300,000+ digits is a big number to factor. And that's at the bottom end, the minimum key length for public-key encryption. We know how fast the best factoring algorithm works, so we can calculate how long it's going to take to do that job and it's measured in hundreds of years. So to make your concern an issue we'd need one or more fundamental breakthroughs in mathematics that make factoring at least 2 orders of magnitude faster than we can currently manage. As someone's noted, betting on fundamental breakthroughs happening is usually not a winning proposition.

Re:Data Theft

[TemporalBeing]

The trick is in the "derives the private key" part. In a public-key system, doing that involves factoring a very large number. Large as in the product of two 1024-bit primes, which is over a million bits. 300,000+ digits is a big number to factor. And that's at the bottom end, the minimum key length for public-key encryption. We know how fast the best factoring algorithm works, so we can calculate how long it's going to take to do that job and it's measured in hundreds of years. So to make your concern an issue we'd need one or more fundamental breakthroughs in mathematics that make factoring at least 2 orders of magnitude faster than we can currently manage. As someone's noted, betting on fundamental breakthroughs happening is usually not a winning proposition.

Problem: Computing power is growing and becoming cheaper. So it's no longer in hundreds of years.

4096 bit keys are minimum now, and 8192 bit and even 16384 bit keys are probably recommended; but even they will get caught up to soon. Yes - I realize that they are very large digit sets to factor, but if you throw enough computing power at it it can be done, and Quantum Computing will do it even faster.

Problem with the GPP was that it assumed one known key. If you had a key generated 5 years ago, it would likely have been a 512 bit or 1024 bit. Through a cluster at it and it wouldn't take as long. Through it to a distributed network and it will be even faster. Fact is - if someone wants to crack it they will. And when you rely on just a single set in PKI, and a set that you cannot change very often - then you are vulnerable. That's part of the problem with PKI, and why most PKI encryption systems are doubly encrypted now (e.g. Diffie Hellman Key Exchange, etc.)

Re:Data Theft

[Skrapion]

You can just store the first and last four digits. That's all the information credit card companies give businesses when they report fraud anyway.

Re:Data Theft

[Threni]

> You can just store the first and last four digits. That's all the information credit card companies give businesses when they report fraud anyway.

No, I mean internally. The first four digits is the range - it tells you which sort of debit/credit card. The last four isn't enough as there are more than ten thousand users of each sort of card.

Re:Data Theft

[jimicus]

Easy enough to do - the router acts as the man in the middle.

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 control the client PC, you can tell it to trust the CA which signs the certificates generated by the man in the middle router - which immediately eliminates the error message. SSL was designed on the assumption that you could control and trust your own PC, but if it's a friends PC, it's a PC at a cybercafe, it's owned by an employer or it's been riddled with malware - you don't control it, someone else does.

Re:Data Theft

[xelah]

You can just store the first and last four digits. That's all the information credit card companies give businesses when they report fraud anyway.

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.

Re:Data Theft

[xelah]

There is no reason that numbers need to be stored - even for subscriptions.

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 you've discovered a connection with other fraudulent orders, for example)? If you have the PAN you can get a message to the issuer who can suspend the card until it's been checked with the holder. If not, you can't. And storing at least hashes of a card number can be useful for detecting the suspicious reuse of a card across multiple transactions, and for refusing cards for which you've received questionable chargebacks in the past.

You are, however, right that it's not actually necessary, but the card industry needs to get its act together. Why is the number which identifies the card so valuable? Why not have an ADDITIONAL number I need for authorization, but not for tying transactions to a card, sending refunds and reporting fraud? CVV is a bit like this, but not quite there...(how about extending the number on the magstripe? how about making it mandatory enough that a PAN alone (or just a unique and usable part of it) isn't valuable and I can store it without too much fear?). Why not give me a special code for continuing authorities (like subscriptions) which I (and only I) can use in place of a PAN? Actually, some payment service providers in the UK used to do this (and used to allow refunds based on a past transaction ID_...but have drastically cut back this sort of thing because of fear of liability arising from keeping all of those card numbers....so they've passed these problems back to the merchants.

Re:Data Theft

[dave1g]

not to mention wireless sniffing

Re:Data Theft

[edrie]

Secure Electronic Transactions (SET) A secure electronic transaction or SET is a transmission security method that are legitimate and securely. Primary the secure electronic transaction is much like an SSL that are encrypt the information using the encryption technologies before sending the information through the world. Dissimilar the SET from the SSL is it enables identification of the customers identity. The customer must give the digital certificate and transaction will be conducted. The digital certificate will validate among the purchaser. Basically the SET are endorsed by major e-commerce players including MasterCard, American express, Visa, Netscape and Microsoft.

Re:Data Theft

[borgboy]

Something resolvable to the number does need to be stored, for dispute resolution. Otherwise the merchant cannot have an intelligent conversation with the bank regarding a disputed charge.

Re:Data Theft

[Skrapion]

They also give you the transaction date and amount. It's more than enough to find what you need to find, unless maybe you're Amazon.

Re:Data Theft

[Skrapion]

It might depend on the company, then. We also get them one at a time by post, but we only get the first and last four numbers, and the date and amount of purchase.

Six letters for this. B O O H O O

[Chas]

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.

Well

[morgan_greywolf]

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]

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:Well

[y86]

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 audit records and better security for everyone involved.

In this economic climate and with the abundance of ULTRA-LOW-COST sellers in the retail world, the last thing on the list for spending money on is items that don't directly generate revenue. You security and data is NEVER the companies priority, your sale is.

DISCLAIMER: I work on POS systems for a major retailer.

Re:Well

[phantomcircuit]

The receipt. See I maybe wrong on this but isn't the signed receipt with the transaction (not the cc#) the audit trail?

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:Well

[ray-auch]

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 typing the number in again - not worth the risk IMO.

Re:Well

[GallaherMike]

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 ticket\invoice number but that is it in most cases. That being said, there is little reason in the US to store the credit card information. Most of the processors will return you a transaction ID that you can use to reference the transaction for follow on things. (like a void) Outside of the US where integrated EFT is not as common this is a non issue as the POS software does not often participate in the EFT process. It is often done with separate side-by-side EFT hardware and the only thing the POS software cares about is that you got an auth. number. Frankly I am more concerned with the idea that the credit card companies would know what I buy than the merchant would know what card I use. I get 5 spam offers a day for more credit cards, but most of the merchants I buy from send me nothing.

Re:Well

[alan_dershowitz]

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:Well

[y86]

I can't get into detail about my companies dealings on slashdot.

Re:Well

[MortimerV]

I was under the impression that the CC companies wanted all high transaction retailers to keep the numbers and implement tight security policies. Is this requirement only for those retailers that do keep CC numbers, and those that don't (if there are any) won't have to do anything special?

Re:Well

[Anonymous Coward]

That won't work at all. That good solution has been tried many, many times. When I worked at Amazon, we tried that failed plan. It requires the credit card companies to do work to add a new feature. That will not happen. They are lazy and incompetent so they are unwilling and unable to do something that sophisticated.

Re:Well

[Anonymous Coward]

Unless you have read the mass overburdening areas that are the PCI-DSS, don't be so quick to blame the retailer. Demanding secure storage is one thing, but the PCI-DSS goes way beyond that.

Re:Well

[alshithead]

The major retailer I worked for sent no merchandise information at all to the credit card companies. The credit card companies have no need for anything other than the account information, sale amount, and merchant ID.

Re:Well

[sjames]

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 of the right thing. When security measures are expensive, the most sensible plan is to keep the sensitive data in one or two very secured locations.

A risk shared is a risk doubled.

All about shifting liability

[gclef]

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)

Re:All about shifting liability

[Anonymous Coward]

This whole security issue is probably a result of upper management(TM) not fully understanding security, maybe not wanting to understand it, and trying to keep costs down. As usual, the underlings will suffer the most. Corp America at it's finest!

Re:All about shifting liability

[rtechie]

Exactly right, please mod the parent up.

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, sometimes as much as $500, for the chargeback plus THE MERCHANT has to prove that the item wasn't defective. In practice this is near-impossible, so the merchant has to soak up the inventory loss too. If someone steals your card and does the same thing, guess who has the liability then?

BTW, If you're paying attention you'll notice that the CC processors actually WANT some level of fraud because it provides them a revenue stream in the form of fines and penalties they impose on the merchant, who soaks up all the loss.

Any change in the laws is likely to shift liability not to the banks or CC processors, but to the customer, which is very bad for the banks and CC processors. The banks an CC companies are VERY powerful in the USA, so this is unlikely to happen.

So my answer to the retailers is: tough shit. If you don't like their rules, you don't have to accept credit cards.

Re:All about shifting liability

[bluedog57]

I agree, its not the technology, its who is liable for it.

Two points:-

First point. 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.

Second point. What is a card number and pin anyway? It looks a bit like a username and password to me. Do you know of any other computer systems that restrict you to a numerical username and a 4 digit numerical password?

My bank sent me a little gadget that I can put my bank card into, enter the pin and it returns "pin correct" and an authorization code. The machine is stand alone and looks like a pocket calculator. If I was in possession of a stolen card I could use this gadget to brute force the pin. Ok it might take me 80 hours to go through all 10,000 pin's by hand, but I bet I can get it a lot quicker for many cards. Start with numbers like 1940, 1941, 1942... up to about 1990 and similar strategies.

No wonder there is fraud.

Re:All about shifting liability

[rtechie]

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 cards, etc.), but the cost of these initiatives was placed squarely on the shoulders of the merchants. They had to buy ALL the equipment, plus pay higher processing fees, plus it wouldn't work for 90% of the CCs out there. Few retailers thought this was worthwhile.

The only technology that's gotten off the ground is the "disposable" credit card #s for online merchants. And that's only because it's really cheap to implement.

a quicker method

[FudRucker]

RE:["it would take several years before retailers could purge their systems and applications of credit card data, he said. Over the years,"]

give me a Linux live CD and access to the keyboard and i could purge them in just a very short time...

Wait what?

[techpawn]

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

TRUNCATE TABLE Customer Data

There ya go!

Re:Wait what?

[Connie_Lingus]

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

Re:Wait what?

[jmyers]

"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

Re:Wait what?

[El_Oscuro]

I think the correct syntax is:

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:Wait what?

[sco08y]

I think the correct syntax is:

DELETE FROM customer_data should work anywhere.

Store it as insecure as you want

[Anonymous Coward]

Throwaway Online Credit Cards

Store it as insecure as you want; I don't give a shit.

Amusing: The shell game

[Bomarc]

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:Amusing: The shell game

[superpulpsicle]

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]

"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:A service for those who don't want to RTFA

[dctoastman]

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.

Re:A service for those who don't want to RTFA

[BlueNoteMKVI]

....but that information is already there in that central database.

I read that as "We recognize that Visa already has this information on file, so rather than create another possible target we'll just use their copy."

The joys of insecurity

[Y-Crate]

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 my car got stolen from the parking lot (afterwards they told me there had been four car break-ins that month, but kept the information a secret from the staff) so it's not like CC receipts were the only insecure items in the place.

Re:The joys of insecurity

[SoCalEd]

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.
  - Hard copy of receipts to reverse chargebacks need to be reprogrammed to only show last four.
  - Hard copy of detail tape and settlement journals likewise.
  - Modify register and pole display programming to obscure card number as well
  - Got old credit card terminals? Oh, bummer. You get to replace them all at a few hundred bucks a pop if they can't be upgraded to Triple DES. Retail math primer: 100 stores * 10 terminals * $300 = $300k plus time and effort to reinject merchant numbers, test, roll-out, etc. Oh. And how long will that standard last?
  - Credit card terminals go down? Rules require taking a manual imprint of the card. Now those copies need to be stored and secured.

And at corporate? Same issues.

  - Delete it from the marketing databases. Delete it from loss prevention programs.
  - Password protect each individual spreadsheet used for reconciling payments and thats still not secure.
  - Also have to make sure nobody can email or otherwise copy the files and take them out with them.
  - When glitches happen and duplicate charges happen, somebody at corporate needs the full number to issue the credit.
  - Years of back-up tapes contain the data too - on-site and off-site.

The biggest problem, and its difficult (and costly) to even insure against, is the virtually unlimited amount of damages which can pile up - even on a retailer trying to do it right. The NRF, of which we are a member, has it right. There is no need for us to store card numbers at all. If the processor and banks have the full number (which they do), then a chargeback request for a signed receipt based upon location, date/time, amount and last four is all that is necessary. I'm not carping about the cost of protecting sensitive data. I'm carping about the cost of being forced by Visa/Mastercard regs to store *unnecessary* sensitive data then having to jump through ever-changing hoops to do so.

TJ Maxx is another issue. They clearly dropped the ball by allowing their kiosks onto their store networks unfirewalled, but anyone who minimizes the cost/effort behind this issue is sorely misinformed.

Oh yeah. Guess who ends up paying these costs?

Re:The joys of insecurity

[CastrTroy]

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.

Re:Six letters for this. B O O H O O

[Anonymous Coward]

I've got 4 characters for you: 9/11

The terrorists will just love this idea. Less traceability, less data to mine and track, less ability to do a postmortem after we crack a cell or after a terror event, like we did with the 9/11 Saudi hijackers, getting ATM info, hotel receipts, you name it.

People like you are treacherous.

Re:Six letters for this. B O O H O O

[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 Ecommerce, and barely addresses network security, uses vague terms like 'deny all access to the server' without specifying specifics or context --- did you mean 'Deny physical to the server' vs. 'Deny SSH access to server' or 'Deny ALL access to the server, which means that my developer can't use a *webbrowser* to "Access the server"'. PCIDSS doesn't always make a distinction between which systems need to be L1 compliant vs L2.

Re:Six letters for this. B O O H O O

[apparently]

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.

why not encrypt?

[Connie_Lingus]

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:why not encrypt?

[Minupla]

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 division, etc.

Min

Re:why not encrypt?

[Connie_Lingus]

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 a low cost to impliment, why not?

Re:why not encrypt?

[Thundersnatch]

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 database, and even if it is not, the app server probably has the same vulnerabilies and probably the same passwords that gave you access to the database. They also typically don't use a unique initialization vector for each database row, so a dictionary attack against the encrypted card data is often dead simple (often the cipher and mode of operation are chosen poorly as well, and there's only about 30 bits of entropy in a credit card number).

Doing encryption key management correctly is not easy. To do it right, you'd need to use public key encryption, or a Kerberos-like system where an entered password can temporarily unlock a copy of the shared encryption key. Better yet, use hardware key escrow. And don't forget the need to revoke keys, and change them often.

It's much easier and safer to just to throw away the card numbers and CVC as soon as you get the auth code from Visa. Right now we keep card data only for as long as it takes the transaction to settle. But it would be best if card data was only ever stored in RAM (and yeah, I know the swapfile is a vulnerability, too).

Re:why not encrypt?

[Josef Meixner]

Right now we keep card data only for as long as it takes the transaction to settle. But it would be best if card data was only ever stored in RAM (and yeah, I know the swapfile is a vulnerability, too).

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. 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 possibly swap file, but I think that is not really a big concern). There seem to be some OSS versions, sorry I only know of them, I have never used one.

Re:why not encrypt?

[Thundersnatch]

And why don't you do that then?

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.

A little more effort, but just use a second database but not the regular kind, but an in-memory database. 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 possibly swap file, but I think that is not really a big concern). There seem to be some OSS versions, sorry I only know of them, I have never used one.

Good idea. From a developer perspective, it would probably be easiest to use the same database application as the rest of the system, with the files stored on a RAM disk instead of on a physical disk. It could be dynamically created at application startup via script with empty tables.

Re:why not encrypt?

[Anonymous Coward]

But it would be best if card data was only ever stored in RAM (and yeah, I know the swapfile is a vulnerability, too). Not in a real OS (read: non-Windows OS). In real OSes, you can allocate pages and indicate that they may never be swapped out of volatile memory for exactly that reason.

Unfortunately if you're using virtual machines it gets somewhat hazier because some VMs can allow memory to be swapped even if the OS doesn't allow it.

Re:why not encrypt?

[sjames]

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 publically available (containing only key signatures, no personally identifying info) and rotates the signing keys (not unlike the way cards expire and get replaced now). That would allow decent assurances for a merchant with an offline system.

Re:why not encrypt?

[Thundersnatch]

Not in a real OS (read: non-Windows OS). In real OSes, you can allocate pages and indicate that they may never be swapped out of volatile memory for exactly that reason.

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 before your knee jerks and you say "Windows can't do that".

Re:why not encrypt?

[Thundersnatch]

Umm... I did mention "hardware key escrow". Which implies either a smart card or a TPM of some sort.

Re:why not encrypt?

[sjames]

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:why not encrypt?

[Thundersnatch]

Okay, you go ahead and convince everybody to change.

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:why not encrypt?

[sjames]

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 that rollout FAST before they started taking large losses.

Instead, they're busy rolling out a new system where you don't even have to take your card out of your wallet to have someone grab the cc number.

The problem w/ IPv6 is that it provides no material benefit to anyone who already has an IPv4 address (it's not faster, easier, cheaper or more secure) and provides practically none to someone who doesn't. If IETF and ARIN had the authority to grant a 10% discount on bandwidth used for IPv6 traffic and if they gave a discount on allocation fees in exchange for v6 deployment, we'd be well on our way by now.

Re:why not encrypt?

[Thundersnatch]

First: the consumers aren't liable for fraud, and neither are Visa or MC. It's the merchants who are liable. So they are the only ones who would benefit from a new smartcard system. Wal-mart and Target and other large merchants need to get their act together and push for something. Visa/MC and even consumers have no reason to do so. Regulation is not the answer - see various smart-card deployment failures in Europe since the 1980s.

Amex actually came out with a smartcard/creditcard combo called, I think, "Blue". It went nowhere in the market, probably because no merchants upgraded their hardware to access the smartcard features. Why wouldn't merchants upgrade, if it meant lower risk? Few merchants accept Amex in the first place, because their fees are so high. And very few consumers carry Amex - it's mostly used by businesses for expense accounts and the like. So why would a merchant spend thousands to accept thier new card? Chicken and egg.

As for IPv6 deployment, I see again you propose some sort of regulation to make things work the way you'd like. I think you're naive if you think effective regulation of the Internet is even possible, or that it could possibly be beneficial. The U.N. can't deliver *food* to starving people without massive corruption and waste - what do you think would happen if they or a similar beauracracy were given control of the Internet?

I'm reminded of a quote:
"Democrats are the party that promise you their government will make you richer, smarter, taller, and get the chickweed out of your lawn. Republicans are the party that says government doesn't work, and then they get elected and prove it." -PJ O'Rourke

Re:why not encrypt?

[sjames]

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 have indicated that the technology exists, opined that it SHOULD be deployed, and offered a possible reason it would get implemented. Of course, that depends on Congress or the courts doing the right thing in spite of big cash incentives from the cc companies to continue allowing them to push the liabilities for their crappy security onto others.

It sounds like the retailers may be starting to apply a bit of pressure now. That is another potential source of pressure. Personally I would love to see them start charging a credit card fee and giving cash customers a break.

As for IPv6 deployment, I see again you propose some sort of regulation to make things work the way you'd like.

Since when is offering a financial incentive (or disincentive) the same as regulation? I got a 2 for one coupon from Brusters this week, a financial incentive for me to give them my business (something they obviously want me to do). Are they regulating ice cream?

IANA wants ISPs to implement v6. They COULD offer a discount on the allocation fees for people who choose to give them what they want.

Re:why not encrypt?

[Thundersnatch]

IANA wants ISPs to implement v6. They COULD offer a discount on the allocation fees for people who choose to give them what they want.

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 registry would likely be set up and IANA would lose its power completely.

Re:why not encrypt?

[sjames]

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 already have a significnt block of IPs somewhere, you can't possibly have those zillions of hosts.

The same policies are filtering down throughout the aftermarket as well.

Of course, if you decide to try starting out with a more modest request, FORGET IT! Theey don't hand out less than a /24 and many routers won't accept a prefix smaller than /24 anyway.

So, apparently IPs ARE scarce now as far as IANA is concerned.

The small provider market is exactly where they should be looking for a transition to v6. That's where they're more likely to find network admins who will "just do it" and actually care about the fees. The big players are mostly heavy on restrictive policies such that even an obviously harmless config change has to be signed off in triplicate by half the world and so are light on action. Additionally, they largely don't care so long as they have their piece of the pie.

If IANA actually waits until there are no more IPs to hand out, it will be far too late to do anything about it, you can't sell what you don't have.

Several Issues

[wardred]

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]

"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:Cash is so easy.

[CastrTroy]

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.

Re:Cash is so easy.

[SonicSpike]

Except that federal reserve notes are illegal because the federal reserve is unconstitutional

additional audit trail requirement

[Anonymous Coward]

you've overlooked the requirement that the audit trail be auditable by credit agency in the event that the credit card "owner" claims the transaction was unauthorized.

if the only audit trail capable of proving whether a transaction was authorized or unauthorized is solely in the possesion of the credit card owner then you've put the fox in charge of the hen house. (how many people do you know whose living rooms would have a huge, flat-screen TV next week if they could force the credit card company not to take it off the bill by saying "of course I didn't authorize anyone to buy a huge plasma TV ... if I did I would have a receipt to show you!"

NRF, Who?

[Anonymous Coward]

The NRF can hem and haw all they like, but the reality is that they have no power here. The real power is in the hands of the issuing and acquiring banks who represent the interests of their customers - the consumers and the retailers, respectively. The facts that consumers are generally paranoid about online transactions and that more and more of them have debit cards nowadays, mean that the balance of power is tipping in the favor of the card-issuing banks. So, like it or not, PCI regulations (which have been in effect for many years) are here to stay and will only get more strict.

PCI is not the law. If you are a merchant and your acquiring bank wants to force you to undergo an audit, you can refuse, but at the cost of losing your ability to accept credit card payments. So the only true recourse for retailers who don't want to or are unable to become compliant is to find a bank that is willing to loosen it's standards and negotiate on the merchant's behalf when conflicts arise (usually this means higher processing fees).

TFA seems to imply that online merchants across the globe will somehow band together and boycott credit cards so they don't have to implement common-sense security measures such as using a firewall, encrypting sensitive data, conducting quarterly security audits, implementing a password security policy, etc. This is absurd. If anything, they should be thankful that there is a standard such as PCI to provide a roadmap to implementing security measures they should already have.

Speaking from experience...

[MattyMatt]

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:Speaking from experience...

[imag0]

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 level of security to be a mandate. The 2008 DSS requires an app-layer firewall. The 2007 is a recommendation for one. I believe in either case a code review is a requirement.

Ok, back to my tripwire migration.

Cheers!

imag0

Re:Speaking from experience...

[cavtroop]

are you saying you **weren't** putting firewalls in front of your application servers, or did I misread you?

Re:Speaking from experience...

[XorNand]

App-level firewall != standard SPI firewall. Take a moment to read up on the OSI model.

Re:Speaking from experience...

[workermonkey]

We are just getting started on the same process. Not only do we have to overcome years of architectural shortcuts, but we have to try to decipher the somewhat vague meaning of network scope. In theory any connected network becomes in scope, so any links to your data center, whether they have access to the data or not, could extend your scope back to your office... which would then need to be as secure.

The standards themselves are a collection of best practices that all make sense individually, but it seems like a protection racket where only the certified consultants can pronounce you pure.

I'd be interested in hearing about any experiences that others have been through for the level 1 certification.

Re:Grammar painful even by Slashdot standards

[heffrey]

Seriously the story title is exceedingly hard to understand (and I am actually English!) so why is my comment flamebait? Oh that's right, the first rule of Slashdot is nobody criticises Slashdot...

It's very simple

[sjames]

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:It's very simple

[eflester]

You have touched a nerve, sir(or madam). I heartily agree with what you say about "identity theft." I had an episode a few years ago where someone used my name etc. to open a cell phone account. I heard nothing about this until the phone co. turned "my" account over to a collection agency. The fact that I had no dealings with the phone co., that they had no signature, picture, no physical proof that I had ever agreed to anything -- this was next to useless and not proof against harassment and the necessity for ME to produce documentation (i.e. spend money) proving/swearing that I had no such agreement. I did/do not have the nerves of steel that it would have taken to do what, in retrospect, would have been correct, that is to simply ignore the harassment and let them sue me. I was annoyed and my peace disturbed because the phone co. in question has, in my opinion, sloppy business practices. That they will extend credit to a person based on a telephone call is their (questionably intelligent) decision; it should not become my problem. But it was. As you say: when the banks and/or credit card companies (and other businesses that extend credit) are made to take responsibility for bad debts incurred in this way the game will change, and quickly. There are those who will say that this would be bad for business. I will remind them of the "Crunchy Dead Frog" sketch from Monty Python, in which the confection company is asked why they don't reveal on the package label that the food therein contains a dead frog with bones in it. "It would affect sales!" is the horrified answer.

Re:It's very simple

[jimicus]

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

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:It's very simple

[sjames]

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

[VampireByte]

"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."

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.

Re:Six letters for this. B O O H O O

[alan_dershowitz]

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 data. You know what, life sucks, I have no sympathy. The standard has been in place for quite some time now. Even before the standard there were minimum practices for storing credit card data, maybe companies should have been following them all along.

It's the POS vendors more than the retailers

[Guysmiley777]

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.

Re:It's the POS vendors more than the retailers

[/dev/trash]

I have a better one than that. I once worked for a Poster Sales company who used DOS, A credit card swiper and plain old over the Internet to conducts sales. I know for a fact that none of the info was encrypted before it was sent ( we didn't do live transactions we uploaded over a modem back at the hotel). This was like 3 years ago. Amazing.

I don't understand...

[cdrguru]

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. Someone decided to try to use my credit card number to pay for three WoW subscriptions. They failed. Blizzard evidently didn't check the cards out too well and didn't question why a US-address card was being used from Australia. Too bad for them, they had to pay the chargeback fee to their credit card processor. This was because they did not invest in enough fraud detection and are not manually checking out these charges that have a high potential of fraud. I suppose the tradeoff is worth it if the volume of non-fraud is high enough.

I hear constantly how much of a problem this is for card holders and I simply do not understand. I have never heard of a card holder being held responsible for a fraudulent charge, ever. I have never heard of anyone other than the merchant getting penalized in any way. The person committing the fraud is never pursued and never has any consequences.

Now, in my opinion it would be very simple to stop 90% of credit card fraud - have the card issuing companies (Visa, MC, etc.) prosecute the people committing fraud. Currently because nobody wants to press charges law enforcement does nothing. Fix this, get some enforcement and the problem will go away. Unlike copyright infringement, most countries will gladly prosecute credit card fraud, if they are given the information and tools to do so. When both the person committing the crime and the crime itself are in the same country there is no excuse for not pursuing it.

No prosecution simply means that the risk vs. reward balance is all screwed up. There is no risk today, just reward. Which is why there is so much credit card fraud.

Re:I don't understand...

[Anonymous Coward]

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.

You really believe that?

I have never heard of a card holder being held responsible for a fraudulent charge, ever. I have never heard of anyone other than the merchant getting penalized in any way.

Which means that merchants' business costs increase or they get a tax write off. Where do you think that eventually comes from?

Re:I don't understand...

[/dev/trash]

And who do you think Blizzard passes those chargeback costs on to?

Re:I don't understand...

[BlueNoteMKVI]

In your particular example, you're correct - Blizzard should have recognized that a charge from the other side of the world might be fraud. Consider some other situations. How many times have you ordered something online to be shipped somewhere else? My grandmother orders all of her Christmas gifts over the internet. She pays with her credit card and ships it straight to her grandkids. Great for her, she doesn't have to mess with packing boxes. The only information those store can possibly validate is the card number, the three-digit code off the back and the credit card billing address. My grandmother lives in Florida and ships me stuff in Texas. How do those websites know that it's not me shipping myself stuff with a stolen credit card number? They don't. Credit card companies don't give merchants much to go with. But if the merchant accepts a bad card, it's all his fault - and he's guilty until proven innocent. When you call your card company to say there's been a fraudulent charge they immediately issue you a credit. Where does that money come from? The merchant's checking account. He'll find out why money suddenly left his account when he gets the packet in the mail in a few days. THAT is why a credit card number is sensitive information. It's too easy to commit fraud, often very hard to trace the criminal, and the responsibility lies with the merchant 100% unless they can conclusively prove that the card holder actually made the charge.

Re:I don't understand...

[Anonymous Coward]

The poor shmucks who pay for WoW, at my guess...

Since I don't, that STILL gets filed NMFP.

Re:I don't understand...

[jimicus]

Two issues:

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).

Re:I don't understand...

[/dev/trash]

Yeah but you certainly buy something,from someone, right?

No one is forcing stores to save the data

[wsanders]

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:No one is forcing stores to save the data

[Anonymous Coward]

No, the standard doesn't prohibit storing the data, only some parts of it. You can store the credit card numbers if they are encrypted, but it neither encourages nor discourages it, it is up to you.

Worse than that!

[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 POS PC needs 4 serial port connections), but recently bought a whole truckload of ~1997-1998 vintage Gateway 2000 boxes with classic Pentium 233MHz cpus that work great, all for $100 the whole lot, so this dry cleaners company will keep running this old system for many years to come.

What disruptions?

[ScrewMaster]

... 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

[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 numbers attached to reports. Now, we're really not a bunch of retards, so our first response was to leave a blank space on our reports and let the customers fill this in themselves. But eventually some of the agencies decided that wasn't good enough, and required that we collect social security numbers from our customers, store them, and print them on reports. So we did this.

Fast forward a few years, not only has SOX put in a whole batch of requirements on companies that store that kind of info (which we have complied with), but some of the "upstream" agencies which we deal with, because of complaints from their membership, are now requiring that we not collect or store social security numbers, while others are still insisting that we do. Fucktards! There are really days when I want to buy a plane ticket and go strangle some of these dumbshits!!!

Solution

[Anonymous Coward]

Can't Wal-Mart step in?

Most of you do not get it

[Anonymous Coward]

This is not about better security, a higher bit encryption algorithm, or "passing the buck"

I have managed retail operations, and according to the current laws they must keep a complete copy of the transaction.
Let us pretend that you made a purchase at store X.

Now, 30 days later you decide that you never made the purchase at store X.
When you file a complaint with your CC company, you are basically demanding that store X show you your receipt.
The receipt must include the date, time, item(s), credit card number and signature(sometimes)...
While most retail operations no longer store a paper copy of the receipt(that is what all of those digital signature pads are about) they still have to store your credit card number in any easily accessible manner.

As far as the people claiming that they need better encryption, they haven't learned anything from social engineering. The weakest link in most security setups is the users. Nobody is getting these credit card numbers in bulk from the main server. They are grabbing them as they see them on the screen. It is similar to the scam that was recently busted where waiters were recording credit card numbers to sell on the black market.

The retailers are trying to cover their asses, but they are probably justified
1)They do not want to have to store ALL of this data
2)They do not want to be in a position where they have to protect all of that data
3)They do not want to constantly deal with customers claiming purchases NEVER happened.

What you will probably see come out of this is the following:
You will not be able to challenge a credit card purchase after a certain time period, and the challenge process will become more difficult. At most major retailers it is already changing. I know for a fact that Sears just overhauled their system so that credit card numbers cannot be accessed by most associates.

Effin' great idea.

[Anonymous Coward]

Posting anonymously to avoid the publicity for my store and my customers.

Many customers come into my store and when they sign their credit card slip they black out the card number. That's damned annoying, because now I have to go reprint the slip. I am REQUIRED to have that card number on file. It's in the agreement that I signed. Do customers like it? No. Do I like it? HELL NO! I really don't want that information laying around.

For what it's worth we don't leave it laying around, card slips are locked up and secured. To steal the card slips from my shop you'd have to get through the outside door, the office door then the locked cabinet. Only those people who need access have the keys.

Why do I need to keep this card number around? It's proof that someone did come in with that card and signed the slip. Officially, if the card doesn't have the full card number on it, it's not valid proof. Yes, I HAVE lost a chargeback because of that. I had the person's signature on the slip but they had blacked out the number. That cost me $50 plus the chargeback fee. Why is a signed slip, with a date, time and transaction ID that can be traced back through the bank's system, NOT valid proof just because the number is blacked out? Card companies refuse to accept any blame that they can possibly shift to the merchant even under stupid pretenses.

I have lots of beefs with the credit card industry but in today's society it would be business suicide to not accept credit cards. 90% of our in-store sales use plastic - and yes, we do still accept checks, green paper and round shiny things as payment. Customers prefer their plastic.

Re:Six letters for this. B O O H O O

[BlueNoteMKVI]

I think you missed the point.

Yes, retailers are complaining about the costs involved in this.

This letter, however, is more complaining that it's necessary in the first place - if retailers were not required to store this data for so long, they would not have any need to protect the data. The card companies have the data already, why does the retailer need a copy as well?

Because you probably messed up..

[Anonymous Coward]

The right way to do this would be to use public key cryptography and encrypt the number in a way that your application couldn't read it. The private key would be kept on a separate secure (non networked) computer where you would use it only when needd. From your description you just used symmetric cryptography and kept the key in your application. Even if you didn't (in which case I apologise for misreading) most people probably would. That doesn't work since the hacker can just look at the app and extract the key. Yes, it provides a small extra technical barrier, but the benefit isn't very big and there is a definite cost.

Re:Six letters for this. B O O H O O

[Chas]

I'm not opposed to not storing CC data.

HOWEVER, bitching about PCI at this late a date is simply bullshit.

There's more evil out there..

[Anonymous Coward]

Just in case you bought into the myth of PIN numbers reducing risk: there IS a risk reduction, but it's not in fraudulent charges. It's in liability for the card issues/bank.

You see, when you sign for a purchase, it's the retailers responsibility to check the signature. There is plenty of evidence that that isn't done very well but that means there will be at least evidence of a forgery. In other words, evidence exists it wasn't you who signed - the bank has to prove you signed it, and a thief will have to at least practise your signature. BTW, I don't know where I picked that up but it appears signatures are best compared upside down - it's got something to do with you then comparing the image rather than the 'text' in a signature.

Now imagine the same situation with PIN numbers. If the thief managed to get hold of your PIN you will have to prove you were NOT the buyer at the time (notice a trend: here again you have to prove your innocence instead of being innocent until proven guilty!). And no effort is required of the thief to replicate something that only you can do well. So if it goes wrong YOU instead of the bank has to do the hard work - you'll be liable for the outgoings until you can prove it wasn't you.

We then get into the question why it's only a 4 digit PIN - a normal bank card in, say, Switzerland has 6 and that works everywhere (I tried). The answer is that I have no idea, but 4 digits are easier to shoulder surf and memorise than 6..

Cash is also very dirty

[cheros]

It has gone through many hands, and you don't know where those hands have been :-)

There are a few issues with PCI

[thogard]

The 1st issue is that to be an Auditor you have to be in the business of selling security stuff. That is a serious conflict of interest.

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 handing off the numbers ends up bankrupt so there there is no blood left in that stone and the banks are just the members of the card schemes so the only ones left are the merchants and now thanks to PCI, the audit companies and their insurance policies.

Is there any wonder why most of the best groups that did past audits won't touch them anymore?

Same problem with paper credit card slips

[lma]

This is not just an electronic problem. My brother-in-law runs two restuarants and recently devcided to accept credit cards. He's required to keep the printed credit card slips in case anyone disputes a charge. After a year as the mountains of paper are building up he's realized that this borders on the ridiculous, and creates a huge liability for him with personal credit card data. What he's doing now is keeping the paper records for 90 days and then shredding them. So he's limited the risk of losing someones card number to the last three months. Most disputed charges seem to happen within 90 days, and he's decided that he'd rather take the losses after 90 days than risk storing all that data. One thing that's important to realize here is that people dispute credit card charges all the time that they actually made. So every month he gets a handful of disputed charges that turn out to be completely legitimate. There would be a lot less need for him to keep records if credit card users didn't dispute so many legitimate charges. Larry

From a Small Merchant Standpoint

[fast turtle]

I'll throw my hat into this discussion.

What I'd like to see is a unique transaction number generated by the primary card company (Visa/MasterCard/Discovery/AmEx) that is 128 digits that includes the CC type, amount of transaction along with an ID for payment. This information is all I would need to hold in my system in order to be paid by the card company and because the ID includes the amount of the transaction, I can't overbill any card.

The advantages are that the card company only has the amount I've billed along with a transaction ID that identifies the billing merchant. This should actually ease chargebacks and damn well stop card fraud because a merchant who continually gets hit with chargebacks of a fraudulent nature can then be cut off from that card network. It also allows the company greater control on the merchant agreements and the rate a merchant actually pays for the privleage of accepting a card.

Calif's AB 779 would inhibit this solution

[Benjamin_Wright]

The National Retail Federation proposes the innovative solution of requiring merchants to store just "authorization code" and "truncated receipt". This is the kind of creative thinking the industry needs. However, this solution might be illegal under California's pending Assembly Bill 779. The words of AB 779 are unclear and poorly defined. For example, AB 779 would forbid a merchant from storing various data elements such as "payment verification code" and "payment verification value". The legislation does not define these terms, and my research finds no clear industry definitions for these terms. (Part of the issue is that different industry players use different words. Further, neither PCI version 1.1 nor its Glossary defines "payment verification code" and "payment verification value".) Therefore, AB 779, if the governor signs it into law, would cause confusion and roadblocks as the industry changes and technology evolves. Parties would not know whether the good data elements they want to store will later in court be interpreted as the data elements AB 779 bans from storage.

Get rid of SSN

[SonicSpike]

Yes, we should get rid of Social Security all together.

Fraudulent transactions

[TT076678 Priya]

The information on the credit cards kept/stored by retailers is for security purpose, to avoid any future fraudulent transactions being made. Storing data's is actually beneficial for the credit cards companies, but where retailers are concern they find it a time and storage consuming. But then again, purging data from the system could face many types of problems in the form of security for both retailers and the credit card companies because data is often associated with range of buyers and removing it would cause severe inconveniences.