Fact or Fiction: Common Misperceptions of Database Encryption
In a recent blog on facts and fiction in database encryption, the author attempts to debunk some common misperceptions that occur. Here we round them up for your consideration.
Fiction:
Encryption is rendered null and void, if an authorized user account itself is compromised.
Rationale:
Just because someone has compromised data (e.g., lost a USB drive containing PII), that doesn’t mean that they or anyone who finds the device has the credentials or know how to decrypt the data. Both the database and the encryption key/application user credentials for this must be compromised, in order to make such a pat statement accurate.
Scenario One:
An individual user creates a key in MS SQL Server, they then protect it with a password or encrypt it with another. Even if someone compromises the database account with the password “Password1”, they still have not obtained the decryption keys. Potential hackers would have to gain access to the key or guess the password. And given that there are likely to be many users’ keys within the context of the query operations, it would take several keys before the correct one is found.
Scenario Two:
In the case of IBM DB2, the database requires one set of credentials, while encryption key access uses another set. Database access requires both. This is particularly the case with Transparent Encryption. Once a user is validated to access the database, their session is supplied with the encryption key and then encryption operations are mapped to relevant/issued queries.
Fiction: encrypting data in any layer (except the application layer) renders your data insecure.
Explanation:
From the standpoint of protecting data in a compromised database, this can be true. However, within the application layer, encryption credentials are safe. Application users can expect the same type of opacity as Transparent Encryption provides database users, so if an application account is breached, it will bypass encryption credentials and access a portion of the data stored in the database.
Sources:
http://blog.formstack.com/2013/3-facts-about-database-encryption/
AIVAnet 