Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Retailers Fighting To No Longer Store Credit Data

Zonk posted about 7 years ago | from the just-going-to-get-stolen-anyway dept.

Security 136

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

Sorry! There are no comments related to the filter you selected.

Is it really that hard? (-1, Offtopic)

Anonymous Coward | about 7 years ago | (#20872169)

The Jews are the enemy. Their bloodthirsty actions and control over teh Amerikkkan government have killed far too many.

While were at it (5, Funny)

Anonymous Coward | about 7 years ago | (#20872197)

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 (1)

Nos. (179609) | about 7 years ago | (#20872583)

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 [wikipedia.org]

Re:While were at it (1)

geekoid (135745) | about 7 years ago | (#20873209)

That's no different then in the US.

I have never had to give any personal information.

Re:While were at it (1)

Nos. (179609) | about 7 years ago | (#20873405)

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 (1)

belmolis (702863) | about 7 years ago | (#20873321)

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 (1)

suitepotato (863945) | about 7 years ago | (#20875137)

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 (1)

Znork (31774) | about 7 years ago | (#20877283)

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

Data Theft (4, Insightful)

KGIII (973947) | about 7 years ago | (#20872231)

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 (5, Interesting)

CastrTroy (595695) | about 7 years ago | (#20872363)

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 (1)

wbren (682133) | about 7 years ago | (#20872585)

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

Re:Data Theft (1)

qbwiz (87077) | about 7 years ago | (#20872589)

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

Re:Data Theft (5, Insightful)

heckler95 (1140369) | about 7 years ago | (#20872829)

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 (5, Interesting)

geekoid (135745) | about 7 years ago | (#20872683)

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 (2, Insightful)

maxume (22995) | about 7 years ago | (#20873731)

So the traffic you were sniffing was SSL encrypted?

Re:Data Theft (1)

jimicus (737525) | about 7 years ago | (#20878133)

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 (2, Interesting)

VTI9600 (1143169) | about 7 years ago | (#20872791)

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 (1)

geekoid (135745) | about 7 years ago | (#20873153)

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 (1)

shofutex (986330) | about 7 years ago | (#20873309)

Perhaps like SET [wikipedia.org] ?

Re:Data Theft (1)

TemporalBeing (803363) | about 7 years ago | (#20873543)

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 (1)

Todd Knarr (15451) | about 7 years ago | (#20874539)

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 (1)

TemporalBeing (803363) | about 7 years ago | (#20876059)

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 (1)

Threni (635302) | about 7 years ago | (#20873915)

> 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 (1)

Skrapion (955066) | about 7 years ago | (#20876063)

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 (1)

Threni (635302) | about 7 years ago | (#20877667)

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

No one is forcing stores to save the data (1)

wsanders (114993) | about 7 years ago | (#20874147)

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 (0)

Anonymous Coward | about 7 years ago | (#20875507)

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.

Re:Data Theft (1)

Midnight Thunder (17205) | about 7 years ago | (#20874331)

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.

Six letters for this. B O O H O O (1, Flamebait)

Chas (5144) | about 7 years ago | (#20872233)

I say "tough".

PCI has been coming for a while now.

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

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

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

Boo fucking hoo.

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

Re:Six letters for this. B O O H O O (0)

Anonymous Coward | about 7 years ago | (#20872485)

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 (2, Interesting)

Anonymous Coward | about 7 years ago | (#20872545)


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 (1)

alan_dershowitz (586542) | about 7 years ago | (#20873629)

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.

Re:Six letters for this. B O O H O O (1)

apparently (756613) | about 7 years ago | (#20872681)

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.

Re:Six letters for this. B O O H O O (1)

Chas (5144) | about 7 years ago | (#20877301)

I'm not opposed to not storing CC data.

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

Re:Six letters for this. B O O H O O (1)

BlueNoteMKVI (865618) | about 7 years ago | (#20876477)

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?

Well (3, Insightful)

morgan_greywolf (835522) | about 7 years ago | (#20872235)

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 (5, Insightful)

MortimerV (896247) | about 7 years ago | (#20872371)

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 (1)

alan_dershowitz (586542) | about 7 years ago | (#20873697)

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 (1)

MortimerV (896247) | about 7 years ago | (#20874363)

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 (0)

Anonymous Coward | about 7 years ago | (#20875619)

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 (0)

Anonymous Coward | about 7 years ago | (#20875417)

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 (1)

y86 (111726) | about 7 years ago | (#20872671)

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 (1)

GallaherMike (987682) | about 7 years ago | (#20873233)

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 (1)

y86 (111726) | about 7 years ago | (#20873877)

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

Re:Well (1)

alshithead (981606) | about 7 years ago | (#20876989)

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 (1)

phantomcircuit (938963) | about 7 years ago | (#20872679)

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?

additional audit trail requirement (0)

Anonymous Coward | about 7 years ago | (#20873045)

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

Re:Well (2)

ray-auch (454705) | about 7 years ago | (#20872989)

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.

All about shifting liability (4, Insightful)

gclef (96311) | about 7 years ago | (#20872269)

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 (0)

Anonymous Coward | about 7 years ago | (#20872913)

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 (1)

rtechie (244489) | about 7 years ago | (#20875221)

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.

a quicker method (1)

FudRucker (866063) | about 7 years ago | (#20872271)

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? (4, Funny)

techpawn (969834) | about 7 years ago | (#20872279)

several years before retailers could purge their systems and applications of credit card data
TRUNCATE TABLE Customer Data

There ya go!

Re:Wait what? (1)

Connie_Lingus (317691) | about 7 years ago | (#20873171)

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? (2, Funny)

jmyers (208878) | about 7 years ago | (#20873341)

"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? (1)

El_Oscuro (1022477) | about 7 years ago | (#20875773)

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? (1)

sco08y (615665) | about 7 years ago | (#20876547)

I think the correct syntax is:

DELETE FROM customer_data should work anywhere.

Store it as insecure as you want (0)

Anonymous Coward | about 7 years ago | (#20872287)

Throwaway Online Credit Cards [digg.com]

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

Amusing: The shell game (1)

Bomarc (306716) | about 7 years ago | (#20872321)

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 (1)

superpulpsicle (533373) | about 7 years ago | (#20872601)

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 (2, Funny)

pushing-robot (1037830) | about 7 years ago | (#20872399)

"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 (1)

dctoastman (995251) | about 7 years ago | (#20872889)

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 (1)

BlueNoteMKVI (865618) | about 7 years ago | (#20876493)

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

Grammar painful even by Slashdot standards (-1, Flamebait)

heffrey (229704) | about 7 years ago | (#20872407)

"Retailers Fighting To No Longer Store Credit Data"?? In ten years, couldn't you even learn how to write in English? Ouch!

Re:Grammar painful even by Slashdot standards (0, Flamebait)

heffrey (229704) | about 7 years ago | (#20873419)

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

The joys of insecurity (1)

Y-Crate (540566) | about 7 years ago | (#20872465)

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 (2, Insightful)

SoCalEd (842421) | about 7 years ago | (#20873101)

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 (1)

CastrTroy (595695) | about 7 years ago | (#20873107)

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

why not encrypt? (1)

Connie_Lingus (317691) | about 7 years ago | (#20872813)

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? (1)

Minupla (62455) | about 7 years ago | (#20872983)

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? (1)

Connie_Lingus (317691) | about 7 years ago | (#20873123)

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? (2, Insightful)

Thundersnatch (671481) | about 7 years ago | (#20876367)

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? (1)

Josef Meixner (1020161) | about 7 years ago | (#20877751)

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 [wikipedia.org] . That way the CC data is in a physically separate database and a SQL-injection in your main database can't get the CC data. Also nothing is written to the disc (except 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.

Because you probably messed up.. (0)

Anonymous Coward | about 7 years ago | (#20877069)

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.

Several Issues (4, Insightful)

wardred (602136) | about 7 years ago | (#20872837)

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. (3, Insightful)

miracle69 (34841) | about 7 years ago | (#20873023)

"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. (1)

CastrTroy (595695) | about 7 years ago | (#20873177)

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.

NRF, Who? (0)

Anonymous Coward | about 7 years ago | (#20873205)

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... (4, Informative)

MattyMatt (57008) | about 7 years ago | (#20873367)

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

imag0 (605684) | about 7 years ago | (#20874041)

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

cavtroop (859432) | about 7 years ago | (#20875371)

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

Re:Speaking from experience... (1)

XorNand (517466) | about 7 years ago | (#20875519)

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

Re:Speaking from experience... (2, Interesting)

workermonkey (1168391) | about 7 years ago | (#20876535)

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.

It's very simple (5, Interesting)

sjames (1099) | about 7 years ago | (#20873463)

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 (1)

eflester (715184) | about 7 years ago | (#20875687)

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 (1)

jimicus (737525) | about 7 years ago | (#20878163)

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.

Bad design rears its ugly head (1)

VampireByte (447578) | about 7 years ago | (#20873561)

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

It's the POS vendors more than the retailers (1)

Guysmiley777 (880063) | about 7 years ago | (#20873809)

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

Worse than that! (2, Interesting)

Anonymous Coward | about 7 years ago | (#20874377)

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.

Re:It's the POS vendors more than the retailers (1)

/dev/trash (182850) | about 7 years ago | (#20875775)

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

cdrguru (88047) | about 7 years ago | (#20873979)

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

Anonymous Coward | about 7 years ago | (#20874323)

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

/dev/trash (182850) | about 7 years ago | (#20875733)

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

Re:I don't understand... (0)

Anonymous Coward | about 7 years ago | (#20876787)

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

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

Re:I don't understand... (1)

BlueNoteMKVI (865618) | about 7 years ago | (#20876311)

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.

What disruptions? (1)

ScrewMaster (602015) | about 7 years ago | (#20874983)

... 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 (2, Interesting)

Anonymous Coward | about 7 years ago | (#20875191)

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 (0)

Anonymous Coward | about 7 years ago | (#20875319)

Can't Wal-Mart step in?

Most of you do not get it (0)

Anonymous Coward | about 7 years ago | (#20875543)

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

Anonymous Coward | about 7 years ago | (#20876461)


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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?