Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Security Privacy Businesses

Retailers Fighting To No Longer Store Credit Data 136

Posted by Zonk
from the just-going-to-get-stolen-anyway dept.
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."
This discussion has been archived. No new comments can be posted.

Retailers Fighting To No Longer Store Credit Data

Comments Filter:
  • by Anonymous Coward on Friday October 05, 2007 @02:29PM (#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.
    • by Nos. (179609)

      Wait, you want retailers to store every bit of data they can about you? Have fun with that. Its the other way around in Canada. I don't have to provide any information to a retailer that isn't absolutely necessary for the transaction. I don't want them storing loads of information on me that may or (more likely) may not be stored securely.

      Personally, I like the idea that I can just say "No thanks" when some sales person tries to collect my name, address, etc. so I can buy some batteries. The best par

      • by geekoid (135745)
        That's no different then in the US.

        I have never had to give any personal information.
        • by Nos. (179609)
          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.
      • by belmolis (702863)

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

    • 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?
      • by Znork (31774)
        "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 biom
  • Data Theft (Score:4, Insightful)

    by KGIII (973947) on Friday October 05, 2007 @02:31PM (#20872231) Journal
    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 (Score:5, Interesting)

      by CastrTroy (595695) on Friday October 05, 2007 @02:43PM (#20872363) Homepage
      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.
      • by wbren (682133)
        Cardspace [netfx3.com] could do something similar, in theory. You might want to look into that. Even though it's from Microsoft, it is pretty cool and surprisingly open.
      • by qbwiz (87077) *
        Paypal seems to be doing just that. Now, we just have the problem of trusting Paypal's servers.
      • Re:Data Theft (Score:5, Interesting)

        by geekoid (135745) <dadinportland AT yahoo DOT com> on Friday October 05, 2007 @03:08PM (#20872683) Homepage Journal
        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: (Score:2, Insightful)

          by maxume (22995)
          So the traffic you were sniffing was SSL encrypted?
          • by jimicus (737525)
            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 con
        • by dave1g (680091)
          not to mention wireless sniffing
      • Re: (Score:2, Interesting)

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

        In a wa
        • by geekoid (135745)
          Credit card companies are not banks.

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

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

      • by shofutex (986330)
        Perhaps like SET [wikipedia.org]?
      • Basically, he told us that SSL, while it's good at what it does, doesn't really solve the real security issues with transactions happening over the internet. Nobody sniffs the wire or does man in the middle attacks to collect the data, because it's often very difficult, and requires physical access to cables.

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

        • by Todd Knarr (15451)

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

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

          • 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 i

    • by Threni (635302)
      > 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, assumin
    • 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.
    • And if they didn't store the data then we wouldn't have the TJ Maxx crap like stuff going on in the first place. Storing it should be illegal - encrypted or not. There is no reason that numbers need to be stored - even for subscriptions. If worse comes to worse then get the lazy bastards to re-swipe or re-enter the card data.

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

      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 y

    • by borgboy (218060)
      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.
  • 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: (Score:2, Interesting)

      by Anonymous Coward

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

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


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

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

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

      • by Chas (5144)
        I'm not opposed to not storing CC data.

        HOWEVER, bitching about PCI at this late a date is simply bullshit.
  • Well (Score:3, Insightful)

    by morgan_greywolf (835522) on Friday October 05, 2007 @02:32PM (#20872235) Homepage Journal
    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 (Score:5, Insightful)

      by MortimerV (896247) on Friday October 05, 2007 @02:44PM (#20872371) Homepage
      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.
      • 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.
        • by MortimerV (896247)
          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?
    • by y86 (111726)

      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

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

        Working on POS systems for a major retailer doesn't mean you have any experience with EFT. What processors do you integrate with? What level of card processing do you support? Your statement seems a little uninformed. I do actual EFT development for a POS software company. We are deployed into thousands of stores in over 70 countries around the world.

        The credit card companies know every item you buy. They have a complete transaction record along with descriptions.

        That is not true. Most authorization requests contain the card information, the amount of the purchase, but not the items. Some processors do require the ti

      • 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.
    • 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?
    • by ray-auch (454705)
      Card companies stored the card account data, retailers store the purchase data. An authentication code for the transaction can tie the two together for audit purposes - no need for retailers to store the card data.

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

      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

  • by gclef (96311) on Friday October 05, 2007 @02:34PM (#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)
    • by rtechie (244489)
      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, so
  • 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? (Score:4, Funny)

    by techpawn (969834) on Friday October 05, 2007 @02:35PM (#20872279) Journal

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

    There ya go!
    • Yeah..but what happens to all the "INSERT INTO CUSTOMER_DATA" calls sprinkled all over the 20 year old legacy spaghetti code?
      • Re: (Score:2, Funny)

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

        5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/purgeCustomer_Data.pl
    • 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
      • by sco08y (615665)
        I think the correct syntax is:

        DELETE FROM customer_data should work anywhere.
  • 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.
  • by pushing-robot (1037830) on Friday October 05, 2007 @02:46PM (#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."
    • 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.
  • Keeping them must be a pain, but securing them should be an easy thing to accomplish. Sadly, it's not something that every store takes great pains to do.

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

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

    Then again, shrink was a huge problem, and
    • Re: (Score:2, Insightful)

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

      - Not all point of sale systems (especially older ones) are set up to only show last four = code modification. If the vendor still supports it.
    • by CastrTroy (595695)
      If it's something that's easy to accomplish, then they should have to take great pains to do it. The fact of the matter is, is that it is hard to do, especially when your employees aren't security engineers, but rather people with absolutely no training in how to keep this data secure.
  • 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.
    • by Minupla (62455)
      Thats part of the mandate of PCI compliance. Problem is, encryption is easy, key managment is hard. Where do you store the keys, who gets access to them? How do you know they're going to do the right thing with them? Who audits these processes? How do you know the encryption process is secure? How do you make sure it stays that way after deployment?

      Encrypt it is an easy answer, but it spawns a lot of harder to answer questions, especially for a smaller company without a security devision, compliance d
      • Right, but a big push behind PCI was to get the CC info off of insecure servers/databases because, in general, the CC companies are mostly worried that individuals are going to hack into poorly-secured e-commerce sites and download tables loaded with CC data.

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

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

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

            • 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 no

          • by sjames (1099)

            Even better would be public key signatures built into the card's smart chip. Merchant presents transaction data to customer's card. Customer authorizes the transaction. Card signs it and returns it to the POS terminal. DONE!

            In this schema, CC number means nothing without a signature. Ideally, the card's public key is signed by the CC company to allow an offline transaction to at least verify that the card was legitimately issued. Even better if the CC company periodically makes a revocation list publicall

            • Umm... I did mention "hardware key escrow". Which implies either a smart card or a TPM of some sort.
              • by sjames (1099)

                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.

                • 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.
                  • by sjames (1099)

                    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

                    • 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, "Bl
                    • by sjames (1099)

                      If you convieniantly ignore the part of my suggestion where the card companies are made liable (really where their existing liability is finally recognized or seen from an economic standpoint, internalizing the externalities) I suppose you might have a stronger argument.

                      As far as amex, you missed the part where I suggested financial incentives. As far as I know, Amex offered none. In fact, if the upgrade costs were to be paid for by the merchants, they offered financial disincentives.

                      In other words, I h

                    • 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 re

                    • by sjames (1099)

                      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

  • Several Issues (Score:4, Insightful)

    by wardred (602136) on Friday October 05, 2007 @03:18PM (#20872837) Homepage
    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. (Score:4, Insightful)

    by miracle69 (34841) on Friday October 05, 2007 @03:31PM (#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".
    • by CastrTroy (595695)
      Cash comes with it's own pitfalls. First paying for purchases over the internet is quite difficult with cash. It's not something you can send over the internet, and not something you want to send in the mail. Also, credit cards have other perks, like chargebacks, extended warranties, and may other amenities. Provided you pay your card off at the end of every month, it actually make more sense to use a credit card than cash.
  • by MattyMatt (57008) on Friday October 05, 2007 @03:57PM (#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.
    • by imag0 (605684)
      A lot of companies (perhaps like yours, perhaps not) are looking into service providers who sweat the particulars of the PCI. That's my job. I have had 3 PCI audits this year, one SAS 70, and another misc bank audit all within the first 6 months of this year. It's a long, and mostly thankless job, but it really feels good to get an excited email from one of my clients letting me know that they passed the ROC and are good to go for another year.

      I, for one, am glad for the PCI and the demand for a certain lev
    • by cavtroop (859432)
      are you saying you **weren't** putting firewalls in front of your application servers, or did I misread you?
      • by XorNand (517466)
        App-level firewall != standard SPI firewall. Take a moment to read up on the OSI model.
    • Re: (Score:2, Interesting)

      by workermonkey (1168391)
      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 seem

  • It's very simple (Score:5, Interesting)

    by sjames (1099) on Friday October 05, 2007 @04:04PM (#20873463) Homepage

    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.

    • by eflester (715184)
      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
    • by jimicus (737525)
      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.
      • by sjames (1099)

        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.

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

  • 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! (Score:2, Interesting)

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

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

      I was having hell locating motherboards that still had ISA card slots for the old Lantastic nics and dual RS-232 serial cards (each
    • I 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.
  • 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
    • And who do you think Blizzard passes those chargeback costs on to?
    • by jimicus (737525)
      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).
  • ... 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.
  • by Anonymous Coward

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

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

  • 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

"Bureaucracy is the enemy of innovation." -- Mark Shepherd, former President and CEO of Texas Instruments

Working...