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

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security The Almighty Buck

Deadline for Better Encryption on Payment Systems Pushed Back Two Years (pcisecuritystandards.org) 91

An anonymous reader writes: The Payment Card Industry Security Standards Council (PCI SSC) has announced (PDF) that it will push back the mandatory implementation of TLS 1.1+ encryption, over the very insecure SSL 3.0 and TLS 1.0 protocols, subject to POODLE attacks. PCI SSC cites "complications" that may come from dealing with EMV chip&PIN cards in the US, the new mobile payment platforms, and browser upgrades for the insecure SHA-1 algorithm.
This discussion has been archived. No new comments can be posted.

Deadline for Better Encryption on Payment Systems Pushed Back Two Years

Comments Filter:
  • Racket!

  • by CastrTroy ( 595695 ) on Monday December 21, 2015 @04:39PM (#51161131) Homepage

    I don't see it as a huge problem simply because this is not the biggest problem that online payment systems face. The big problem isn't people sniffing transactions over the wire. This almost never happens. What typically tends to happen is that somebody breaks into the actual system that houses all the sensitive information and steals the data directly. This is much more lucrative as you can steal thousands (or tens of thousands, or even more) of credit card numbers at the same time.

    Until we get to the point where online retailers aren't storing this data (in 99% of cases they don't need to), there's little reason to complain about much smaller problems such as what encryption methods are being used.

    We'd be much better off with a system where we didn't even have to send our credit card numbers to the online retailer. Ideally when paying for something online, you would be redirected to your banks (or the credit card issuers) web site with information on where to direct the money. After verifying you identity, a cryptographically signed message would be sent to the recipient site so they could verify the payment was successful. There is no reason for them to every see your account number or other vital information.

    • by Anonymous Coward

      Almost like PayPal

    • by swb ( 14022 )

      Couldn't credit cards be a little like those RSA cards with a number that changes every minute?

      When buying things, the number gets entered as part of the transaction, verifying that the card is in the hand of the cardholder.

      • Not quite RSA type, but one time pads.

        http://www.creditcards.com/cre... [creditcards.com]

      • by Anonymous Coward

        There are better ways than that. Just sign the transaction with your private key. This is a solved problem. No need for fussy timing, and no threat or replay of MITM attacks. You just look at the terms of the transaction, and if you like them, sign it and off it goes to the payment processor, which will in turn sign it if all is good and return it to the merchant. The merchant now has proof the payment processor agrees to transfer the money, so they can perform the transaction without fear. Some of the part

      • by mlts ( 1038732 )

        What would be nice, would be an e-Ink display on the card that would change over time or when a button is pressed. If the card expires in 2-4 years, that is well within the time of a battery's lifetime, especially for a TOTP system.

        This way, online purchases are protected by a form of 2FA as well, since an attacker would have to have the card info, as well as a challenge/response code.

    • The one cause for real concern with the PCI SSC is that whatever mistakes they make now will be with us when we are feebly waving our canes at the kids on our lawns.

      EMV dates back to 1994(with smartcards more generally being a late-80's thing); and we've just started to pretend at actually being serious about using it. Merchants hate upgrading POS hardware(which damn well earns its name; but at least it's surprisingly expensive), every change means a knife-fight over processing fees and an attempt to sho
      • "an attempt to shove liability onto merchants"

        FTFY

        You think the intent is to shift liability to card holders? Wrong. Merchants are captive. Card holders can change brands, go to prepaid, or go to cash. Online merchants fear this the most, since issuers that try to shift liability to card holders risk those card holders going to cash (yeah, some will), and well no one pays cash for Amazon goods.

    • We'd be much better off with a system where we didn't even have to send our credit card numbers to the online retailer. Ideally when paying for something online, you would be redirected to your banks (or the credit card issuers) web site with information on where to direct the money.

      So I go to a random website to make a minor purchase and it pops up something that looks like my bank's website and asks me for my bank login details? No thanks. I don't want to worry about distinguishing my real bank website from a forgery and putting my banking credentials at risk every time I buy something.

      I enter my credit card number with the confidence that if I see an unexpected transaction show up on my bill I can contest it and get it reversed. Nobody can compromise my bank account just by knowing

      • Really, I try not to buy off sites that look too shady. But a lot of the foreign sites have really good deals, and also look shady. Here's the options:

        A) Going to some shady website and entering your credit card info directly into the website where it is saved on their insecure servers forever.

        or

        B) Going to some shady website and being redirected to a site you can guarantee belongs to your credit card provider and verifying you identity there. And then they just hand off a payment token to the shady site

  • They just need more time so that the government can implement their back doors into the new algorithm

    • No, the algorithms and libraries in question for TLS 1.1+ are already out. Now if they mandate a new cipher then that would be opportunity for backdoors

    • It's more that some of the big banks would no longer be PCI-DSS compliant.

      Imagine most major CC payment provider suddenly ceasing to exist. ;)

  • by rubycodez ( 864176 ) on Monday December 21, 2015 @04:52PM (#51161217)

    Choosing convenience over security with continuing to allow known weak and broken ciphers, PCI just lost all credibility. May as well dissolve it.

    • Choosing convenience over security with continuing to allow known weak and broken ciphers, PCI just lost all credibility. May as well dissolve it.

      What is wrong with AES CBC ciphers in TLS 1.0 with record splitting? A workaround known and implemented since at least 2002?

      Honestly the credibility lost for me was crying wolf on TLS 1.0 without supporting technical merit. This is a fixed problem for vast majority of clients.

      • Not crying wolf, TLS 1.0 includes too many weak and broken ciphers, you just cite 1 that might be "good enough" and not all servers allow a specific single cipher to be specified

        • Not crying wolf, TLS 1.0 includes too many weak and broken ciphers

          Acceptable cipher suites are configurable by client and server independent of TLS version.

          you just cite 1 that might be "good enough" and not all servers allow a specific single cipher to be specified

          No, I cited a _class_ of them.

          ECDHE-RSA-AES256-SHA
          DHE-RSA-AES256-SHA
          AES256-SHA
          DHE-RSA-AES128-SHA
          AES128-SHA

          There are other good algorithms besides AES:

          DHE-RSA-CAMELLIA128-SHA
          CAMELLIA256-SHA
          DHE-RSA-CAMELLIA256-SHA
          CAMELLIA128-SHA

          • >> Acceptable cipher suites are configurable by client and server independent of TLS version.
            Not a true statement for web servers, clients and libraries in general. You are thinking only of Apache or openssl?

            Not all clients do record splitting either; again you seem to be thinking of specific product

  • Why do they not mandate TLS1,2 with PFS?

  • by stevel ( 64802 ) * on Monday December 21, 2015 @05:06PM (#51161343) Homepage

    I run an e-commerce store and have to deal with PCI compliance. We don't store credit card details, but the info passes through our server. The June 30, 2016 deadline to drop TLS1.0 was a big headache, made worse by the "Trustwave" PCI checking tool (mandatory from our payment processor) failing us as of July 2015 for not dropping TLS1.0, but I could submit a remediation plan every three months to defer it.

    I did a bunch of testing to see what broke if I dropped TLS1.0. On the web browser side, MSIE10 wouldn't like it, but other, reasonably current, browsers were ok. What surprised me, though, was how many email clients simply stopped communicating with our server if I turned off TLS1.0 for SMTP and IMAP. It's been hard to find details on which clients support TLS1.1 - and perhaps there's some aspect here I'm missing - but this to me is the bigger problem than the web service. (Even though we don't use email for sensitive info, if TLS1.0 was enabled on ANY port, we fail.)

    I'm glad to see that this deadline was pushed back, as it was giving me heartburn.

    • Why not just host email on a completely different system? There's very little reason to have email hosted on the same machines as your web server.

      • by Alioth ( 221270 )

        That's not how PCI-DSS works. It doesn't matter if your MX is on a different continent, and it doesn't matter if no credit card data ever goes on it. if it supports a weak cipher or weak protocol you fail. Bizarrely, for things like your MX, you can pass by simply not supporting encryption at all.

    • I'd be looking at moving that email server out of scope, ie out of your PCI environment.

      You'd need some policies around your use of email (ie "We don't send cardholder data via email", with bonus points if you have a way of 'enforcing' that, eg a mail scanner) but with that in place there should be no reason why your mail server is in scope if it's seperate from your PCI environment (ie hosted elsewhere).
    • It's been hard to find details on which clients support TLS1.1 - and perhaps there's some aspect here I'm missing

      While there is some variability in how clients may implement or require certain features, 99% (yes, I just made that up, but a high%) of applications will use a library for tls connections, so capability is determined by the library it uses, and there aren't that many. For example, the majority of Windows applications, and certainly the ones provided by Microsoft will use SChannel which supports TLS 1.2 as of Win7, although it may not be enabled by default. Likewise, Apple applications like Mail.app use Sec

    • I have the same issue, except mine was with advertisers and the API. Disabling TLS1.0 for the site disables it everywhere since they all go through the same load balancers. Suddenly a bunch of the advertisers that use the API couldn't use it anymore because their Java implementations were so old, it didn't support anything newer. I'm sad that PCI moved it back, because it means, once again, the business will force the deadline back, and I'll have to submit the stupid trustwave things every 3 months say
  • by PvtVoid ( 1252388 ) on Monday December 21, 2015 @05:16PM (#51161455)

    I got my EMV card from my bank, which is one of the few that is actually implementing the cards with a PIN. (Hooray for my bank!)

    Guess what? I have found exactly one store where it works: Target. Every other store I've been to, every one, still uses the mag stripe and a signature, with the exception of Rite-Aid where they couldn't accept my card at all and I paid cash. Store personnel are whinging to high heaven about how horrible EMV cards are, how this will never work, how it's totally unreasonable of the banks to force this on them, etc. etc.

    Go to Europe? It's been working seamlessly for twenty years now. Why the fuck are Americans so fucking stupid?

    • by Anonymous Coward

      You do not even need to go that far. Just north of the border, Canadians are also using pin&chip cards just about everywhere. Even debt cards are now pin&chips.

      • When I was a cashier at wally world (very recently), I was there when chip cards had to now be inserted, not swipped. I don't think I need to tell all of you how idiotic most of the public is. My store was in a higher income area too. I became so sick of explaining to people how to do it that I just did it for them. But I loved when Canadian customers came through my line. I would tell them they were awesome and always so nice. Also, we had a couple week-long fuck ups with the system that required EVERY chi
    • I use the chip at trader joes. It does seem like most of the time I'm just swiping the card. Of course people are resistant to change and are going to complain. Most of them will get used to it.

      I just wonder how much this will actually help with reducing fraud. EMV prevents the card it self from being cloned. How does it prevent someone for hacking the store and using the information to purchase something online?

      • What annoys me is trying to predict which I need to be using - swipe or chip. Walmart is chip only. Most of my other stores are swipe only.

    • Re: (Score:3, Insightful)

      by taustin ( 171655 )

      National retailers who do their own software, like Target (who had a hell of an incentive) and Home Depot (who also had a hell of an incentive) are ahead of the curve. Anybody who relies on software vendors for their processing software is at said company's mercy, and the software companies (who end up on the hook for any expensive mistakes) are very cautious. Our vendor didn't like the beta testing, and decided to not throw us in to the Christmas season with software they weren't confident in. We did not

      • by Anonymous Coward

        Not sure that fewer people in Europe have credit cards and in the UK at least, chip and pin is used for debit cards as well. In any case every merchant needs to support them.

      • What drove this in Europe was their extremely high fraud rate, it was much higher than US. With chip and pin they brought it down to US levels after many years and now they are a little below US levels except for card not present (online) which of course is where the fraud has shifted to.
      • There is no difference to the consumer. Their protections are legal, not technical (and if you believe otherwise, you probably need a more honest bank). The only difference is some liability on disputed transactions shifts from the merchant service or card holder's bank to the merchant

        Correct me if I'm wrong, but I don't think this is the whole story: the big advantage of EMV from a consumer perspective is that merchants don't store the card data, since every transaction has a unique code. This was the mechanism of the Target hack, which EMV shuts off. It's a big difference.

        • Unfortunately from what I understand you are wrong. It takes services like Apple Pay to tokenize transactions. I have no idea why, but I guess it is a backward compatibility issue, and the merchant's desire to track customers.

      • We all have bank card which are like credit card except with a chip and pin and are accepted in all shop. A lot of shop accept CC too, mainly shop where you can buy good with a big price. For example all mediamarkt accept CC.

        Basically your "Not everybody has a CC" hide the fact that actually we all have a bank card which fulfill the exact same need, and has chip and pin.
        • by houghi ( 78078 )

          There are also pre-paid cards without a swipe strip. Just a chip. And the bank card is basically a Debit Card.

      • by houghi ( 78078 )

        Ever heard of scaling?
        The cost in Europe was higher, because there are less cards. Also people in Europe use the cards less and use cash more than in the US.
        The cost of the card is easily recuperated in the lower amount of theft.

        So the price per terminal is higher in the EU (and the rest of the world). Yes, the total sum will be higher in the US, but looking per transaction and per user and per terminal it will be lower.

        The terminal can be had for less than 100USD easily. And then you will have a high end o

    • So I'm guessing you bank with Chase. The recently sent me a chipped card. Also, CVS forces you to use EVM if you have one
    • by MobyDisk ( 75490 )

      Your experience is the opposite of mine: I live in a major metropolitan area, and the only place I've seen that does not suppor chip+pin in the last 6 months is on the vending machines at my office. I think every other store supports chip+pin. That includes: McDonalds, Target, Kohls, Home Depot, Giant Food, and the little cafeteria at our office. Maybe not the chocolatier around the corner.

  • https://twofactorauth.org/ [twofactorauth.org]

    Vote with your feet and money

  • As of last week, my work no longer accepts incoming connections via SSL or TLS 1.0. SSL was disabled early in the year, and TLS 1.0 recently.

    A few of our larger clients were caught off guard, and took a few sleepless days/nights to fix, though we had been warning them for 18 months. We still get connections, which are refused, and their support teams notified.

    This is really not so simple for some, as they have old, brittle systems. But must be done. The PCI cabal is failing here, but that's their model

"Marriage is like a cage; one sees the birds outside desperate to get in, and those inside desperate to get out." -- Montaigne

Working...