7

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.

Improve this question
8
  • This is kind of a broad question, and the answer is a matter of opinion. Here's mine: If you want your users to feel more secure, let them create a second password just for decrypting. They can always use the same password as their login password, so it gives the paranoid users the peace of mind, while keeping it easy for the normal users.
    – Greg
    Aug 8, 2012 at 17:03
  • the issue is, 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.
    – lynnyi
    Aug 8, 2012 at 17:06
  • You're right that using the hash as the decryption key is bad. To do it right, you need to require the user to re-enter the password, and use the plaintext to decrypt the key.
    – Greg
    Aug 8, 2012 at 17:08
  • I see, so the plaintext password is used to encrypt the private key. So what I'd have in the database is: hashed password, private key encrypted with plaintext password, and message encrypted with private key. Hm... trying to think if there may be risks from so many dependencies.
    – lynnyi
    Aug 8, 2012 at 17:13
  • The security is only as good as the user's password/passphrase. Encourage them to use something sufficiently long and easy to remember, and your security will be fine.
    – Greg
    Aug 8, 2012 at 17:16

2 Answers 2

Reset to default
5

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).

Improve this answer
4
  • 1
    how could you handle password changes with this?
    – Philipp Kyeck
    Mar 15, 2014 at 11:52
  • 1
    Usual method is indirection: from the password are derived two keys, one for authentication and one for encryption. The key for encryption is not used to encrypt the data directly, but to encrypt a symmetric key K (chosen randomly); when you change the password, you have to use the old password to recover K and then encrypt it again with the key derived from the new password. That way, you don't have to decrypt and reencrypt the whole bulk of the data.
    – Tom Leek
    Mar 17, 2014 at 22:25
  • sorry to dig this up again ;) but what if the user lost his/her password? then the data is lost as well, isn't it?
    – Philipp Kyeck
    Apr 23, 2014 at 8:16
  • 1
    Yes, in case of password loss, the data is lost. One method is to use escrow: the data, or the encryption key for the data, is also encrypted with a public key. The sysadmin keeps the private key somewhere else (not on the server itself) and uses it to salvage the data of people who forgot their password. Of course this means that the sysadmin can decrypt users' data, which may or may not be appropriate to your case. Alternative: the user writes his encryption key on a paper and keeps that in a safe, to be used in case of emergency.
    – Tom Leek
    Apr 23, 2014 at 10:52
1

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.

Improve this answer
2
  • Thanks for the response. Question in reply: How do current systems with only one password do this? For example, fb only has one password, and I'm hoping they're decrypting some of the more sensitive information (i.e. messages) I have attached to my account.
    – lynnyi
    Aug 8, 2012 at 17:23
  • Presumably, they do encrypt it, but when you logon, it is available for you. Encryption protects against database leaks. Suppose, I am able to hack FB database, if all data is encrypted, I cannot do much. The question you posed was what if someone gets hold of your password, how to protect against getting your info. In this case, you need to have something else standing between you/hacker and the data. Facebook has two factor authentication I think. Google I am certain about. They send SMS to you as soon as password is verified. You need to enter code that is sent via SMS.
    – Nasir
    Aug 8, 2012 at 17:27

You must log in to answer this question.