Encrypting credit card numbers in a database

You need to encrypt a set of clients' credit card numbers (or social security numbers, or tax file numbers, or some other field that needs to be kept secret) in a database along with their other details.

Here's how not to do it, followed by some better methods.

Method 1

Let's start with a simple database table of clients with their credit card numbers.

Well, you could just store it like that. Frighteningly, lots of big stores seem to do that. They may have a secure SSL connection for you to submit your credit card number, and, yes, it is impossible for anyone monitoring your internet connection at that time to get your credit card number, but then the silly idiots go and store it on their database with your number in the clear for any disgruntled employee or hacker to find. DO NOT DO THIS!.

Method 2

Database systems like Microsoft Access have an option to format a particular field in "password mode", so, when viewed, the table looks like

This might look good to a casual onlooker, but anyone with any knowledge of the database can extract the underlying data without a problem. DO NOT DO THIS!.

Method 3

000102030405060708090A0B0C0D0E0F1011121314151617

Let's use the simplest mode of symmetric encryption, the Electronic Code Book (ECB) mode. This does not require any initialization vector and is probably the default mode in your encryption package. We do, however, need to pad our credit card input data to make it an exact multiple of the Triple DES block length of 8 bytes. In the examples that follow, we use the PKCS#5 method of padding.

Our first encryption operation in ECB mode is:

PT="1234-5678-9789-0124"
PT(hex)   =313233342D353637382D393738392D30313234
PT(padded)=313233342D353637382D393738392D303132340505050505
CT(hex)   =0BDC16E6A777C535C49F67688C6D4E21D3F36088C206C85A

Completing all the encryptions, our database table, with encrypted credit card number in hexadecimal (hex) format, becomes

OK, we have just used the FIPS-approved Triple DES encryption algorithm with a secret 192-bit key to encrypt our clients' credit card data. Couldn't be safer, could it? But, er, look at the results a bit closer here.

0BDC16E6A777C535C49F67688C6D4E21D3F36088C206C85A
0BDC16E6A777C535264AF5FD1E8BD570DDD44E842A72C00B
5408551E9C4A0F8FC49F67688C6D4E21D3F36088C206C85A

An encrypted form of a given input is meant to be indistinguishable from a random value. Do these results look random to you? No, they are not. Simply put, ECB mode is not secure - DO NOT USE IT!

Method 4

The best modes to use when encrypting are either Cipher Block Chaining (CBC) or Counter mode (CTR). These modes require that we use a unique Initialization Vector (IV) each time for a given key. Counter mode has the advantage that no padding is needed, but you need to be especially careful never to re-use an IV.

Let's add a new field to our database, IV, which will contain an 8-byte number randomly-generated each time the record changes. The chances of such an 8-byte IV value repeating with a proper random-number generator are infinitesimal. So now we'll generate a fresh, random 8-byte IV for each record, store this separately in the clear (which is OK), and produce a new set of encrypted credit card numbers using CBC mode.

This method is secure, providing you

1. always use a new, freshly-randomly-generated IV every time you encrypt a new number or if you change someone's card number
2. keep the key secret
3. secure your system against unauthorised access

Method 5

So now your database administrator complains about having to add this new "IV" field. Well, why not join the IV value to the encrypted credit card number and store the concatenated value in the form

[IV] || [Encrypted credit card number]

So the same database can be stored like this

And when you need to decrypt the card number, you need to parse the value first to split off the IV. For a given block cipher algorithm, you always know exactly how long the IV will be. For Triple DES it is 8 bytes; for AES it is 16 bytes. So, taking the second example above, the concatenated encrypted value is

18DF733256D44E322874919B17EFEDFCCC0206723C26A003087D10A271449323

IV=18DF733256D44E32
CT=2874919B17EFEDFCCC0206723C26A003087D10A271449323

PT=313233342D353637312D393938382D373736360505050505

313233342D353637312D393938382D37373636

1234-5671-9988-7766

Method 5a: Using base64

To shorten the length of the encrypted string before storing, we could use base64 encoding instead of hexadecimal.

Method 5b: Using AES-128

000102030405060708090A0B0C0D0E0F

Our input data is the same as before.

For AES we need to use a 16-byte IV, so we generate a new value for each record

To encrypt the first record, we have

KEY=000102030405060708090A0B0C0D0E0F
IV =7AD3C3BF888C9E88AA5F44773FAEB42E
PT="1234-5678-9789-0124"
PT(hex)   =313233342D353637382D393738392D30313234
CT(hex)   =612B4B355C9874F920AC346BD0F8C5C7614165

Note that padding is not needed with CTR mode and the output ciphertext is the same length as the input. This has the advantage that there is no padding to remove when decrypting and less data to store, but you lose the check for correct decryption provided by CBC mode with PKCS#5 padding.

Repeating this procedure gives the following ciphertext values

The resulting table is as follows:

Method 6

In a database with an automatically-generated ID, each new record is guaranteed to have a unique ID value, so you could, in principle, use just the ID number as the IV, suitably padded to the required block length.

The problem with this is that, if a client changes their credit card number, then you are using the same IV to encrypt a different value - DO NOT DO THIS!.

A more secure approach is to randomly generate, say, the first eight bytes and then append the ID number to make the required 16-byte IV.

So you only need to store the 8-byte random component instead of full 16-byte value. The chances of getting the same IV is still impossible, provided your random-number generator is OK. Appending the unique record ID makes it even less likely you will get the same value. Don't worry about all the zero padding bytes in the IV values here; an IV just has to be unique. In this case, you save 16 hex characters in the output string, with the minor downside that you now need to reconstruct the full IV when decrypting. (You could go even shorter and just generate and store, say, 4 random bytes - the odds of getting the same 32-bit value are still 4 billion to one. But don't go any shorter than 4 bytes.)

Using this method, the table would be

To decrypt, say, the third example above, we read the fields from the database

ID=3
CreditCardNum=A9043A577688BD35BD99442B4265B7E8E0AF9E3B700665E37A1CCC

IV = [random 8 bytes] || [ID padded to 8 bytes] = A9043A577688BD350000000000000003

CT=BD99442B4265B7E8E0AF9E3B700665E37A1CCC

KEY=000102030405060708090A0B0C0D0E0F
IV =A9043A577688BD350000000000000003
CT =BD99442B4265B7E8E0AF9E3B700665E37A1CCC

PT =313233342D353637382D393738392D30313234

3456-7898-9789-0124

Summary

• Always encrypt sensitive data like credit card numbers. Never rely on people "not looking".
• Use a recognised block cipher algorithm like Triple DES or AES-128.
• Use CBC or CTR mode, never ECB.
• Generate a fresh random IV every time you save a new credit card number or edit an existing one.
• Store the encrypted value in a normal text string using hexadecimal or base64 encoding.
• Concatenate the IV with the ciphertext value to avoid an extra "IV" field.
• To save space, randomly generate only a part of the IV and concatenate with the unique record ID to get the required length.
• Methods 4, 5 and 6 above are secure (or, more accurately, are as secure as the minimum of the security of your encryption key and the overall security of your system).

Contact us

Any comments, feedback, questions to our email or use our Contact Page.

This page last updated: 26 May 2008

Copyright © 2008 D.I. Management Services Pty Limited ABN 78 083 210 584, Sydney, Australia. All rights reserved.
<www.di-mgt.com.au>    <Cryptography Page>