Storing encryption key?

Question

I am doing a password manager in Java. But now I am VERY confused because of the encryption. There will be the program login, where the user types its password, and it compares to a SHA512 hash. If it matches, the user logs in, if it doesn’t, then the user doesn’t login. I think there is no problem at this point.

And then, I am using AES to encrypt the user saved passwords. The user logs in, and then clicks on an "decrypt" button to decrypt his saved passwords.

My problem is, how am i going to do this? Because I thought for a bit, and... the decryption key must be saved somewhere. But it cant be in plain text... PLUS it needs to be exactly 16 chars long.

I created a thread on Reddit - http://www.reddit.com/r/java/comments/2awvjt/storing_encryption_key/

They give me several options, but none seems to be what I want. Why? Let's see 3 options a user gave me:

1. Store the encryption key. Not secure in the least

2. User has a password that is used to encrypt the encryption key - Pretty secure and usable

3. User has a private encryption key that you don't store. Very secure, very usable.

Well these are my opinions:

1. Obviously I’m not going to use that one, since the key will be stored in plaintext.

2. Well, I can hash the encryption key! But the hash must be stored somewhere! And its the hashed encryption key that’s going to be used to decrypt the user passwords... so I can use 16 chars of it. It is not user friendly if the user needs to set and remember a 16 char password! So i guess this is NOT secure

3. If I don’t store it, how am I going to decrypt it?

So, what can you suggest me?

Answer 1

First, using only a single SHA512 to hash the password is not enough. You should use something like bcrypt with a long salt to store user password "hashes". A simple SHA512 can be attacked quite powerful with a dictionary attack, just trying millions of possible passwords and calculating the SHA512 hash for that until one matches.

Concerning the encryption of other users passwords. Best would probably be to use a KDF (key derivation function) like PBKDF2 or SCrypt to derive a key (or keys) from that. These can be used to en/decrypt the stored user passwords.

But do not just apply e.g. AES directly to these passwords. Put the passwords in a suitable format e.g. XML or JSON and encrypt the serialized structure using a good AEAD scheme like GCM etc. Or use CBC but attach a MAC (HMAC or CMAC) to it. But always Encrypt-then-MAC !

Answer 2

I second the suggestion of a strong password based KDF, e.g. PBKDF2 or scrypt, which you use to derive the encryption key(s) from the user's password. Additionally, use authenticated encryption (e.g. either AES GCM or AES CTR + HMAC).

If you can't open the encryption using the key derived from the password they enter, you know the password was wrong. No need for a separate login step.

There is one situation where you might want to use a more complicated setup. That's if you need to upload the data somewhere. In that case you could generate a random data encryption key, which you in turn encrypt using the password-derived key. That way the encrypted data alone doesn't allow a password guessing attack. However, in that case losing the encrypted keyfile will lead to loss of encrypted data as well.

So, what can you suggest me?

The final suggestion I have is to not use this for any crucial data, like important passwords, unless you are very sure you get everything correct. There are existing programs for that, which are (hopefully) written by programmers knowledgeable about cryptography.

Of course, as a learning experience it's a great problem to try to solve.