Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was wondering which is the best way to encrypt and decrypt user data in a database, to make it much more secure as it is possible?

I was reading about AES but I would like to know if is really the best way.

I was planning to use AES and a secrete key for encrypt/decrypt, is there any better way?

share|improve this question
up vote 2 down vote accepted

AES is a good choice for encrypting data, if you implement it properly. If you're encrypting data in a database, you're going to run into the DRM problem - i.e. you can't maintain data confidentiality through cryptography if you put the encrypted data and the key in the same place. An attacker with access to the machine can simply steal the key at the same time as the data.

Your best bet for keeping sensitive data secure against live attacks is a HSM, which is designed for exactly this scenario.

If you're only worried about offline attacks, e.g. someone stealing your server's hard disk, then you should encrypt your database on a TrueCrypt volume, or use full-disk (system) encryption.

share|improve this answer
so HSM for server machine hardware, i think, right? – Badaboooooom Oct 1 '12 at 10:03
sincerily i was planning to make users login by an hash code wich is AES enctrypted and decrypted anytime user log into site. The encryption uses a unique secret key (stored in application file) – Badaboooooom Oct 1 '12 at 10:05
It's worth noting that storing data in an encrypted form also prevents the use of indexes with ranges and partial matches for retrieving data. – symcbean Oct 2 '12 at 11:04

Secure, yes, but against who or what ?

Regardless of how you encrypt data, your server must still be able to decrypt it. So any attack which subverts your server (e.g. buffer overflows or SQL injection) will yield full data access to the attacker, regardless of your encryption.

Encryption will do you any good only against attackers who get backdoor access to the storage, e.g. who steal a backup tape or recover an old hard disk from a dumpster. Then, this points to the kind of encryption you need: Transparent Data Encryption (equivalently, a full-disk encryption, as hinted at by @Polynomial). TDE does not remove confidentiality needs, but it concentrates them: you "just" have to worry about the encryption key, which is small and does not change over time, instead of gigabytes of ever-mutating data.

(Of course, if you want to sprinkle encryption all over the server just to ease the qualms of some administrative hierarchy somewhere, then forget all of this and just go for an algorithm with the most impressive-looking acronym, preferably with a very long key. "RSA-8192 and AES-256/CBC with HMAC/SHA-512" will reliably plunge the average bureaucrat into an ecstatic trance.)

share|improve this answer
If the SQL injection leads to full access of the whole server then you're right. If the SQL injection just exposes the encrypted contents of the fields and the key is stored somewhere else on the server (your application code, some file or in shared memory), the data is still secure. – chiborg Jun 19 '14 at 9:24

Maybe someone could answer your question definitely but I have the impression that your question is somewhat akin to "Who is the best physician to treat illness X?" Anyway, AES is an ISO standard and has long been examined by the experts in the public without yet any serious faults beng found and is considered to be secure even when quantum computers are available. On the other hand, a secure algorithm alone of course doesn't yet provide you any security.

share|improve this answer
what about using AES + encryption/decryption secret key? – Badaboooooom Oct 1 '12 at 9:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.