Where do we store key/passphrase/salt for encryption?

Question

My app needs to encrypt some data (a user session token). Most examples I see around have a method that generates a Key using a passphrase and a salt, like:

public static Key generateKey(char[] passphrase, byte[] salt) {
    ...
}

My understanding is that we have three options for generating the passphrase:

1. Have the user enter it every time the app starts (annoying to the user).
2. Hard-code the passphrase into the app itself. More convenient for the user, but someone can find out what your passphrase is given your app binary.
3. Randomly generate a passphrase, but then we have to store the generated Key on disk. Now we've just shifted the problem to having to store the key securely on disk, which also seems impossible. If the attacker finds the generated key, big problem.

Option #1 won't work for me. Options #2 and #3 seem inherently flawed, unless I'm grossly misunderstanding how to go about this (hoping that I am). What's the recommended way to do this if we can't go with #1? Do we put in a bunch of obfuscated hoops for an attacker to jump through and hope for the best?

Thanks

Answer 1

"Do we put in a bunch of obfuscated hoops for an attacker to jump through and hope for the best?" Basically yes. The size and number of the hoops being how hard you want to make it.

If you are not using a server, then whatever you do to obsfucate and encrypt your data is reversible. However, you can make it REALLY hard. For example, a technique I used to protect some video assets.

1. Replaced the first 1024 bytes of the header (it's MP4) with 1024 bytes taken from the middle of one of the apps image assets. I tried several repairers, all of which failed to automagically recover the file - although it can be done manually. Then...

2. Encrypted the file using a private key which is 256 bytes taken from another image asset.

3. When the key is extracted, it's hashed through an algorithm which does all kinds of otherwise non-sensical maths to mangle the key.

4. Used a pre-compile obsfucator.

I've tried myself to reverse engineer this, even knowing how it's done, and it's so hard as to make the effort not worth the result.

There are numerous discussions on SO which summarise as; If you simply want to stop copying, make it difficult (cost vs reward) but otherwise sleep easy because there is ultimately nothing you can do. If the data is commercially sensitive, then a server coupled with system level security (e.g whole device encryption and no root) is required.