Encrypting/decrypting information in database

Question

So, let's say I have a secret message I want to encrypt and store in my database, from where an authenticated user can retrieve, decrypt, read, update the message.

EDIT: the issue I'm encountering is this: It doesn't make sense to use the same password for authorization and decryption. Usually, a hashed password is stored in the database in order to verify the user. But if I use the hash password for encrypting the message too, then all a hacker needs to do once he sees the database is decrypt the message with the hashed password

From doing some stackoverflow searches (http://stackoverflow.com/questions/2388256/secure-encrypted-database-design?rq=1), now correct me if I understood it incorrectly, it seems as if the solution is to encrypt the secret message with public keys, decrypt the message with private keys, and then symmetrically encrypt these private keys with user passphrases. The encrypted private keys can then be stored in the database. So in sum, this is how it works: the user provides a passphrase, which decrypts the private key as stored in the database, which is then used to decrypt the secret message as stored in the database.

Now, my question is this: can you use the passphrase for both authentication and decrypting the message? I don't want hackers to be able to guess passphrases until the private key is successfully decrypted, so some user authentication (i.e. username, password, store hashed password in database) would be good. However, the idea of having to enter both a password for authentication and a passphrase to decrypt the message seems excessive.

I believe I may be misunderstanding the linked post, but my ultimate question is how can I structure the security system so that the message may be encrypted in the database (in the event that someone gets unauthorized access into the database) without having one person's password being the key to the decryption.

Answer 1

YES YOU CAN.

It is possible to use the same password for authentication and for data encryption. What you need is to derive from the password, using your favourite key derivation function, a sufficiently long password-dependent stream. You then use the first half of the stream for authentication (that's the part you store in the database), and the second half as encryption key.

For the KDF, use for instance PBKDF2, with SHA-256 as internal hash function. Adjust the iteration count so that the computation is tolerably expensive (a high iteration count slows everybody down: your server, and an attacker who would try to guess the password; so make it high). Make sure that you select a new, random, big enough (say 16 bytes) salt for each password (you will store the salt along the hash value in the database). Generate 32 bytes with PBKDF2; use the first 16 bytes as authentication token (stored in the database), and use the other 16 bytes for encryption (with a proper symmetric encryption system, preferably one with integrated integrity check, such as EAX.

If you apply all that and do not botch the implementation, you will be sure that when you will get hacked, it will be the user's fault (e.g. one user will use the name of his dog as password).

Answer 2

I think you are aiming for a layered security model. So you want to be able to to encrypt the data using some key, but that key should be independent of password. So if the password is stolen or hacked, data is not compromised.

Security can be based on

• something you have (physical SSH file, secureID device, SMS code that is send once password is verified)
• something you know (password)
• something you are (biometrics)

In this case, what you want to do is combine multiple things to provide stronger protection. You already have password, so it is best to pick from something you have, or something you are.

Biometrics might be an overkill for your scenario, so I would recommend, something you have.

You could verify something they have, such as one of those one-time pad (secure ID devices), or you only allow connection through SSH, implicitly verifying SSH keys (which have been pre-registered). You could also send an SMS to a registered device, and ask user to match the code. If it is a match, you decrypt the data. Here the choice of the key would not be that important. It can be independent of user, and also be unique for every user.

For more expert advice, I would recommend heading over to the https://security.stackexchange.com/, hopefully someone can point you in the right direction.

This is also becoming popular as Two-Factor authentication.