Good Crypto Done Badly
Background
Sometimes you have to encrypt data inside your database either due to regulations like the PCI-DSS or because it is a good thing to do. Passwords are typically encrypted, so are credit card numbers. But these two sets of data are used differently and therefore should be encrypted differently.
In the case of a password, it never has to be retrieved in it’s original form. All that is needed is to check that the same password was entered in the authentication attempt is the same one entered in the last password change. This can be easily done by a one-way hash function like SHA-256. You just use the same one-way hash function to hash the password entered in the authentication attempt and compare the stored hash with the computed hash.
On the other hand a stored credit card number needs to be unencrypted so that your process that communicates with the payment processor can actually send the credit card number and not an encrypted string. This requires a reversible encryption algorithm like AES-128 or Triple DES. These algorithms’ security rely completely on the ability to keep the encryption key a secret. These algorithms are good crypto, so how can you implement them them badly?
Example
A well intentioned programmer decided to use Triple DES as the underlying cypher and understood that the key must be kept a secret. He created an Oracle package (a group of stored procedures, stored functions, and common data variables) where he included an encrypt and decrypt function. He then used the Oracle “wrap” utility to “encrypt” the package because the key he used was hard coded into the package.
Why is this “Good Crypto Done Badly”?
The underlying cypher is good. And this method will protect the data stored on backup tape. However, it completely negates the need for knowing the key to decrypt the data in a live environment. A SQL Injection attack can reveal the decrypted date (in this case credit card numbers) without knowing the key.
How can it be fixed?
Without any more overhead, the programmer can split the key into two parts. One of which is compiled into the program accessing the database and the other inside the wrapped package. Then the half of key that is compiled into the program is passed into the encrypt and decrypt routines. This alone will greatly complicate the attacker’s job.
