I'm referring to this article here:


"In addition to using skimmers, thieves also obtain debit card information by installing data-stealing software in card readers and through data breaches, where they hack into the main computer systems where card information is stored."

It would seem to me that most payment systems would encrypt all the credit card information at this point (making the information itself un-obtainable?), and that perhaps there are still some businesses out there that don't, and this is how it's being done? Social engineering of people who control the databases? Crappy/easily understandable encryption algorithms?

  • 3
    You underestimate how many crappy online shops there are which don't meet PCI requirements...
    – Matthew
    Apr 3, 2017 at 11:28
  • 5
    You might as well ask, "why aren't all computer systems perfectly designed, implemented, and maintained?" People are involved, and that's where the trouble starts
    – schroeder
    Apr 3, 2017 at 11:42
  • 1
    As an example of crappy ways how some companies manage your financial data, have a read of this one: troyhunt.com/… Apr 3, 2017 at 12:09
  • 1
    My last employer stored corporate and individual credit card information in a plaintext Access database on a shared network drive. Their insistence that they needed to retain this information to combat fraud outweighed my concerns over its liability-- the contingency plan was to change the company name (again) and pretend like nothing happened.
    – Ivan
    Apr 3, 2017 at 15:09

1 Answer 1


It would seem to me that most payment systems would encrypt all the credit card information at [the database] (making the information itself un-obtainable?)

You are correct that all payment systems should encrypt the credit card information at the database. However, your assumption that this makes the information unobtainable is incorrect.

Most simply, the data in the database is there to be used. In order to be used, it must be decrypted. Therefore, the legitimate business systems and users must be able to decrypt it. An attacker will either access it while it is legitimately decrypted, attempt to compromise the encryption keys, or use the legitimate processes that leverage those keys.

Here's a quote from the PCI Security Standards Council's PCI Data Storage Do’s and Don’ts

Some cryptography solutions encrypt specific fields of information stored in a database; others encrypt a singular file or even the entire disk where data is stored. If full-disk encryption is used, logical access must be managed independently of native operating system access control mechanisms. Decryption keys must not be tied to user accounts. Encryption keys used for encryption of cardholder data must be protected against both disclosure and misuse. All key management processes and procedures for keys used for encryption of cardholder data must be fully documented and implemented. For more details, see PCI DSS Requirement 3.

So, let's consider three methods of encrypting card data that is in a database, and the weaknesses which allow attackers to get the card data anyway:

  1. Full-disk Encryption
  2. Transparent Data Encryption
  3. Application-layer Encryption

Full-disk Encryption

With full-disk encryption (and with file-level encryption of database files at the OS level), the data is only encrypted when the database is not running. In order for the database to run, the files must be decrypted. With something like Bitlocker, EFS, or LUKS+dm-crypt, once the filesystem is unlocked (usually at boot time) the data is readable just as if it was not encrypted.

Once the files are unlocked and the database up and running, the attacker can query cards out of the database using SQL. They can copy the decrypted database files off the system and peruse their contents. They can even use something like 'strings' and 'grep' to pull information out of the files from the command line.

Full-disk encryption protects the data if someone steals the server or the disk. It does not protect from an attacker who gains access to the running system. It does encourage dual control (DBAs might require IT to unlock the disk for them).

Transparent Data Encryption

TDE is similar to full-disk encryption, except that it it maintained at the DBMS (Database) level rather than the OS level. And it has the same weakness; once the database is spun up and the keys provided to unlock the data, the data is available to users, and abusers, of the system as if it were not encrypted.

Once the database is up and running, the attacker can query cards out of the database using SQL. That's the whole "Transparent" thing.

Unlike full-disk encryption, TDE often puts both the keys and the encrypted data into the hands of the DBAs.

Application-layer Encryption

Under Application-layer Encryption, the encryption keys are held by the application, and sensitive data is stored encrypted in the database. Since the database and the application code usually run on different servers, this provides a layer of separation - an attacker who gains complete control over the database server cannot decrypt the data unless they also compromise an application server.

Data is decrypted in a "just in time" fashion; only discrete card numbers are decrypted as needed. Unlike the other two options, the entire data set is not sitting around decrypted in a running system.

An attacker needs to compromise both the keys and the data, or compromise a decryption process (e.g., if they can run the application program that pulls a card out and decrypts it, then they can pull and decrypt until they're caught).

Application-layer systems support the advantage that decryption can be logged by the application. If the attacker compromises a process rather than a key, they may generate a logging trail which makes their activity obvious. If it is normal to see 200,000 decrypts an hour, and that jumps to 2,000,000, something's going on.

Dual-control is somewhat standard with Application-layer encryption.

So - three different methods, some stronger, some weaker. All meet PCI requirements. All can be compromised by an attacker, because all allow legitimate users to access sensitive data.

  • The reason for my suprise is encryption makes it so super computers couldn't crack it in a reasonable amount of time, but I suppose most businesses don't properly store their information. Doing so is expensive, and security professionals still make mistakes....internet security is such a complicated topic it makes my head spin Apr 4, 2017 at 17:26
  • @thinksinbinary encryption is like a safe - it's only tough to crack when it's locked. And just like a bank safe, during business hours it has to be unlocked and open in order for business to occur. If a merchant kept their card database locked 100% of the time, they could never use those cards to charge customers. So they have to unlock it to use it, and that's where the attackers get in.
    – gowenfawr
    Apr 4, 2017 at 17:29

You must log in to answer this question.

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