62

Nowadays there are a lot of hacked websites with stolen login information. In many cases the website states that no credit card data and/or payment information was stolen.

Why is that? What I assume is: That both, the database storing the payment data and the one storing user-credentials are separated from each other. So far so good. But what I do not understand: Why shouldn't they be able to find access to the database storing payment information?

The latter is still visible/accessible from the outside; that is because users of the website can also view/add/edit their own payment information, e.g. whether they want to use paypal/credit card/IBAN. So the database is obviously accessible from the "outside world".

tim
  • 851
  • 7
  • 13
  • 18
    A lot of payment providers will exchange payment information for a token that can be used to refer to that information on their systems without actually having it in the clear (and no, you can't go back and exchange the token for the information itself). So the breached systems only hold references to payment data stored on separate systems. – André Borie Dec 22 '16 at 09:10
  • 27
    To slightly extend on the above comment, many sites just don't store the card data themselves - it's a lot of hassle in terms of security and regulatory compliance. This leaves a few major providers taking care of that extremely sensitive data and as we can see by the number of times payment data is exposed compared to the number of breaches- seems to work quite well. – iainpb Dec 22 '16 at 09:47
  • 1
    Most often - either lying or cluelessness. Take your pick. – AviD Dec 22 '16 at 10:09
  • Also maybe because online payment data (as opposed to physical card's magstripe data) is actually worth less than usernames/passwords - most cards today have 3D secure enabled which makes cashing them out online pretty hard, and a card number, expiration date and CVV isn't enough to go to the ATM and cash it out. – André Borie Dec 22 '16 at 13:10
  • 2
    If you're talking, specifically, about the company I think you are, it's worth noting that it has been reported they (or some companies, at least) do store payment details, and irresponsibly deny it whenever there's a leak etc. –  Dec 22 '16 at 13:46
  • 3
    Reminds me of the old question, "Why can't they make the entire airplane out of the same materials used in making the *black box*?" – Michael Dec 22 '16 at 22:29
  • 1
    The sad part is the credit card numbers are precisely the stuff you (as a consumer) *wouldn't* care about, because (a) they're easy to replace, and (b) you're not responsible for fraudulent charges in the first place. So, really, they're not protecting you; they're protecting the credit card companies. You'd wish they would actually protect you... – user541686 Dec 23 '16 at 02:33
  • Among other things, the major credit card companies are exceptionally good at detecting bogus transactions. They won't tell you, of course, but they probably detect and "bounce" 75% or more of the bogus transactions that are attempted, without informing the customers. Credit card numbers are incredibly easy to get -- one just needs to find a unscrupulous cashier in a small shop, eg. High-tech breaching is not required. – Hot Licks Dec 24 '16 at 19:44
  • Not stolen *more often* than *what*? – Eric Lippert Dec 24 '16 at 23:12
  • @EricLippert - I'm assuming he means more often than expected. –  Jan 04 '17 at 10:45
  • @JᴀʏMᴇᴇ: Well then the answer is simple: *because your expectations and reality are different*. Get better expectations and then stuff will be stolen as often as you expect it to be. – Eric Lippert Jan 04 '17 at 13:06
  • @EricLippert -- funny, but a bit too pedantic nonetheless. –  Jan 04 '17 at 13:47
  • @JᴀʏMᴇᴇ: I'm not trying to be pedantic or funny; I'm trying to point out that the question is not well-posed. Suppose I asked you "why do baseball pitchers not throw more strikes?" This seems like a pretty vague question. "More strikes than *what*?" would be a perfectly reasonable follow-up question, and if I said "Well I don't know how many strikes are thrown, or how many *should* be thrown, but I do know that however many are thrown, they *should* be throwing more, so why aren't they?" Would you characterize that question as answerable? I wouldn't. – Eric Lippert Jan 04 '17 at 17:17

2 Answers2

107

PCI DSS

The major reason for this is a decade long effort by the payment cards industry to limit the extent of such breaches by requiring everyone who handles payment card data to either (a) conform to a set of security practices and (usually) audit requirements, or (b) stop handling payment card data themselves and delegate it to someone who can handle this better.

You shouldn't underestimate the second part - while pretty much all sites handle their own user account data, the vast majority of sites (especially smaller ones) that accept credit card payments do not store credit card data in any way whatsoever; if they do want recurring payments without asking CC number every time, they instead store 'just enough' information to show the user (e.g. a partial card number) that this card is "remembered" plus a token issued by their bank/gateway/whatever that enables additional payments from this card to the same merchant - so these tokens are useless to an attacker.

While it's not 100% proof and there are many, many cases where PCI DSS is blatantly violated, it does mean a significant reduction in the number of vulnerable companies.

Peteris
  • 8,369
  • 1
  • 26
  • 35
  • 24
    People rip on PCI a lot (including most definitely sometimes myself). And it (most definitely) has its shortcomings and absurdities. But I also have no doubt that the payment card security picture is much better today than it would be if PCI didn't exist. If only (as you astutely point out) because the burdens of complying with it push companies toward farming out accepting and/or storing payment info to firms who deal with the security and compliance aspects of that as their main course of business. – mostlyinformed Dec 22 '16 at 16:52
  • 9
    For anyone interested what "[PCI DSS](https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard)" stands for, [here is a link to the Wikipedia page](https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard). – Uwe Keim Dec 23 '16 at 07:40
  • 2
    While I don't know the specifics, I know that our organization does this. When we process credit cards in any form, our merchant account provider only provides us with a "token" that can uniquely identify the credit card within their system, but we can never see, or verify, anything about the card details. Even if a disgruntled employee with unlimited access to our internal systems leaked every database we have, no useful credit card details would be revealed. While not everyone does this, I expect it's more common than not. – phyrfox Dec 23 '16 at 14:57
  • 2
    I've worked on this once before, when a major online service (two, actually, with the same parent company) was hacked. We cleaned up some issues, including using a machine-generated encryption key for the PCI database. The encryption key is protected by a two-part passphrase that is only ever stored encrypted with itself; if the service has to be restarted the key has to be restored by members of two separate teams within the company. Nobody ever has the whole passphrase, and you have to have the passphrase to get access to the encryption key. – Wexxor Dec 23 '16 at 19:13
10

In the case of recently disclosed Yahoo data breach where 1bn user account information was stolen, it transpired that no credit card information was stolen because it was kept in a separate database in encrypted format.

Most organisations have rigid and robust methods to store credit card information, typically in a separate database and encrypted. This helps organisations to protect highly sensitive data against data breaches.

HadidAli
  • 560
  • 3
  • 10
  • 4
    "Encrypted" is only of limited use -- you have to have a decryption key accessible to be able to decrypt that data for it to be used, after all. Even if the key is in a hardware token, it's necessarily in a hardware token *which can be asked to perform decryption requests* whenever your servers are up and processing requests. Having it be a separate system is of much more value than whether content on that system is encrypted at rest. – Charles Duffy Dec 22 '16 at 19:26
  • 2
    (If the hardware element storing the key were limited to a fixed number of decryptions per day, set based on a maxima for expected traffic, *that* would add some value -- but it would also mean that if you had a really good sales day for some unexpected reason, you'd suddenly stop being able to process charges partway through it; a retailer who would agree to such a measure isn't something I can conceive of). – Charles Duffy Dec 22 '16 at 19:28
  • 8
    This answer seems a bit tautological honestly. Why not store *all* information in a separate, encrypted database? – djechlin Dec 23 '16 at 07:48
  • @djechlin, okay, I'll bite: Because, then, what would it be "separate" *from?* :) – Wildcard Dec 24 '16 at 12:58
  • @Wildcard put a dummy account with one piece of fake information in it, and separate everything else from that. – djechlin Dec 24 '16 at 13:46
  • 1
    @djechlin It's about not giving the all of the server side software that implements the whole site access to credit card data. By keeping credit card data separate, it is also possible to only allow certain code dealing with payments to handle it. – DepressedDaniel Dec 25 '16 at 01:36