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

  • 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. Commented Dec 22, 2016 at 9: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
    Commented Dec 22, 2016 at 9:47
  • 1
    Most often - either lying or cluelessness. Take your pick.
    – AviD
    Commented Dec 22, 2016 at 10:09
  • 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.
    – user81147
    Commented Dec 22, 2016 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
    Commented Dec 22, 2016 at 22:29

2 Answers 2



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.

  • 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. Commented Dec 22, 2016 at 16:52
  • 9
    For anyone interested what "PCI DSS" stands for, here is a link to the Wikipedia page.
    – Uwe Keim
    Commented Dec 23, 2016 at 7: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
    Commented Dec 23, 2016 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
    Commented Dec 23, 2016 at 19:13

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.

  • 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. Commented Dec 22, 2016 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). Commented Dec 22, 2016 at 19:28
  • 8
    This answer seems a bit tautological honestly. Why not store all information in a separate, encrypted database?
    – djechlin
    Commented Dec 23, 2016 at 7:48
  • @djechlin, okay, I'll bite: Because, then, what would it be "separate" from? :)
    – Wildcard
    Commented Dec 24, 2016 at 12:58
  • 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. Commented Dec 25, 2016 at 1:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .