I want to encrypt serialised customer details and store in a database to protect against attacks where the attacker has access to the raw database records. The records then need to be accessible by multiple logged-in users, but do not need to be indexed nor searched.

The naive approach would be to use a system-wide key for symmetrical encryption using AES or similar, however I'm not sure that this is any more secure than no encryption at all.

Is it generally safe to say that raw DB access is more of a threat than source code access? Assuming so (which I believe to be the case in my situation), is there a better approach that I can use than one system-wide key?


2 Answers 2


The problem with direct access to the database is that users can extract large amounts of data e.g. SELECT * FROM TableName.

If you encrypt data in the database using transparent encryption, the users with access to the data see the encryption transparently or, in other words, they see clear text data. Even if they see encrypted data, they may have a view configured to see such data in the clear.

You could consider encrypting the data at the application layer. This means the data would be encrypted within the database so DBAs would only see encrypted data. The application can then decrypt and publish data depending on user privileges. This could be tuned so end users only see single pieces of data at a time rather than lists or volumes and logging could be enabled so you can identify who has accessed what data.

Then you need to consider how your key management is implemented so the encryption key used by application is not stored somewhere in clear text and is not available to any user. AES with a bit length of 128 or greater is a perfectly reasonable symmetric key to use.


Assuming you mean "read the source code" and not "modify the source code" when you say "source code access", then Kerckhoffs's principle applies and you're indeed correct that raw database access is a bigger threat. That's not to say you should make it easy for anyone to get your source code, but ideally your system should be designed so that you're not inherently vulnerable if your source code is leaked.

I can't imagine a way in which attackers could have access to the raw database records and still be secure. Your users will need a system to convert those records into something useful, and if it's a key then you're depending on somehow giving users the key in a secure way that attackers could never compromise. You'd need to either use something like Shamir's Secret Sharing algorithm to give each user a unique key, or change the key (and reencrypt your database) with a high frequency so that ex-users won't be able to access the data. This assumes that your attackers will never be users and never be able to compromise user's systems and never be able to find your key on your server. If you mean that attackers can insert or update database records when you say "the attacker has access to the raw database records" then there's nothing you can do to prevent your system from getting completely taken over. The whole thing screams "bad idea".

Generally, users access databases through a web page or program, and it's only that web server or software that has database access. The web page or program handles authentication and restricts what users can do to prevent attacks. The web page or program should be written so that it won't access the records for your users until it has authenticated them against credentials stored on your backend server; this prevents attackers from getting your data much more effectively than giving your database away and trying to find an encryption algorithm that will be fast for users and resist bruteforcing by attackers, and a method of implementation that will sufficiently protect your decryption key.

All that being said, AES would be an acceptable algorithm if you really, really wanted to do it that way in spite of all the reasons it would be a bad idea.

You must log in to answer this question.

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