Java Encryption: What seed to use in my AES/CBC/PKCS5Padding scenario

Question

I am building an app that will use AES/CBC/PKCS5Padding method to encrypt user's data on their device, and security is of high importance. I want to prevent brute force attack in case someone gets hold of the database.

Each row in the table has an associated title. I am not sure what to use as the seed. I can do one of the following:

1. Hard code my own seed in the source, but I believe this can be read if someone decompiles my app

2. Use the title entered by the user as the seed

3. Use a concatenation of my own seed as well as the entered title

Unless there are other ways, in all the above scenarios, I can visualise someone figuring out the seed. Will this be useful to them in being able to brute force the encrypted data? Of course in all the above scenarios, I also include the User's password as a part of the key.

How can I make it more difficult for a potential hacker?

Edit (Re-Edited)

Based on the replies below and my research and thought process. I think I can do the following.

1. Have the user enter a password, but not store it in the database
2. Before storing the sensitive data, they have to enter a Label to identify it. I will store this as clear text in the database and use it as a salt
3. I will use the user's password and Label with PBKDF2 to generate a key, but will not store it
4. I will use the generated key from #3 to encrypt the sensitive data
5. To decrypt, I will again generate the key based off the user's password and row label and will use it to decrypt the sensitive data

Does this sound right? Will a hacker be able to deduce anything if they get hold of the database with the two columns - label clear text, and encrypted data?

Edit 2

I am planning to build an Android App to be specific and the following links were bang on what I needed.

https://nelenkov.blogspot.in/2012/04/using-password-based-encryption-on.html?m=1

https://android-developers.googleblog.com/2013/02/using-cryptography-to-store-credentials.html?m=1

Answer 1

The problem here is that, whenever someone decompiles your application, the method of generating your key is trivially known. Therefore, if all of the input data to that key generation is known, generating the key is trivial.

Because of that, you might want to provide the user with the possibility to enter a passphrase that will be used with the AES encryption. Make sure that you use a system such as PBKDF2 in order to make it difficult to brute force the passphrase.

If your database is not stored on the user's device, but rather externally, then you might get away with generating and storing a secure random key on the device, and encrypting the data before it actually gets stored in the central database.

Answer 2

As per my comment and your edits, a possible solution boils down to this (I'm not really a Java programmer, but the below pseudo-code should be clear):

aesKey <- PBKDF2-SHA512(userPassword)[:32]
hmacKey <- PBKDF2-SHA512(userPassword)[32:] // PBKDF2-SHA512 has a natural 64 byte output

iv <- CSPRNG(16) // 16 byte IV for AES from a CSPRNG
ciphertext <- AES256CBC(plainText, aesKey, iv) // Use PKCS5Padding

result <- iv + ciphertext // Prepend the IV.
result <- HMAC-SHA256(result, hmacKey) + result
// Prepend the HMAC of the IV and ciphertext using the hmacKey.  Always encrypt THEN mac.

A couple of important notes:

• You should always include the IV in the HMAC, e.g. don't HMAC just the ciphertext.

• The selection of SHA512 and SHA256 is important. Since SHA512 has a natural output of 64 bytes, it is perfect for deriving two 32 byte keys using PBKDF2. If you adjust this algorithm, then you'll be using more than just the final PBKDF2 iteration to generate the next lot of bytes, which isn't beneficial.

• The salt that you use for PBKDF2 isn't actually that important. You could randomly generate this and store it alongside the ciphertext, however, a static salt for PBKDF2 would be fine in this instance.