Derive salt from password - How (in)secure is it?

Question

I got the following problem: In an Java Application I want to store some configuration data in an encrypted, local file. This file might be used for confidential data, like user credentials.

This file should be accessible by using a password (and only a password). Now most trustworthy people and reference implementations use random salts. I completely understand that this is a reasonable choice. But if my application terminates and will be started later, the random salt is not available anymore. This application is stand-alone so no additional database could be used as a salt store.

For my software the user shall only type in the password (means: no user name, no salt, no favorite animal or colour).

Now my idea was deriving the salt from the password (e.g. by using the first 16 bytes of SHA-256).

My questions are:

• How (in)secure would this implementation be?
• What is a common way of encrypting stuff with only a password and would be a better alternative?

What is not the aim of this question:

• Where to store salts
• Secure algorithms and crypto implementation (of course, I did not implement crypto by myself)
• Architectural improvements (nop, I do not want a global database for storing stuff)

Answer 1

To encrypt data, one needs a key not a password. There are key-derivation-functions to get a key from a user password.

A salt can be used for password hashing, but it cannot be used for encrypting data. There is a similar concept for encryption though, the random values there are called IV or Nonce and are stored together with the encrypted data.

The best thing you can do is

1. use a key-derivation-function with a salt, to get a key from the password.
2. With the resulting key you can encrypt the data.
3. In this case the salt can be stored inside the encrypted data container (the IV is already there), so there is no need for a global database.

To answer your original question: Derriving a salt from the password negates the whole purpose of the salt, it just becomes a more complex hash function.

Answer 2

First, I strongly recommend against devising novel encryption formats if you can help it. It is very difficult to do them correctly. If you want an encryption format that does what you're describing, see JNCryptor, which is an implementation of the RNCryptor format. The RNCryptor format is designed precisely for this problem, so the spec is a good source of information on how you could create your own if you don't want to use it directly. (I'm the author of RNCryptor.)

See also libsodium. It's a better encryption format than RNCryptor for various technical reasons, but it's a bit harder to install and use correctly. There are several Java bindings for libsodium.

When you say "of course, I did not implement crypto by myself," that's what you're doing. Crypto schemes are more than just the AES code. Deciding how to generate the salts in a novel way is implementing crypto. There are many ways to put together secure primitives (like salts) in simple ways and make them wildly insecure. That's why you want to use something well established.

The key take-away is that you store the salt with the data. I know you said this isn't about storing the salt, but that's how you do this. The simplest way to do this is to just glue the salt onto the start of the cipher text and store that. Then you just read the salt from the header. Similarly, you could put the whole thing in an envelope if that's more convenient. Something as simple as JSON:

{ "salt": "<base64-salt>",
  "data": "<base64-data>" }

It's not the most efficient way to store the data, but it's easy, standard, and secure.

Remember, salts are not secrets. It is fine that everyone can read the salt.

---

OK, enough of how to do it right. Let's get to your actual question.

Your salting proposal is not a salt. It's just a slightly different hashing function. The point of a salt is if the same password is used twice (without intending to be the same password), then they will have different hashes. Your scheme fails that. If I implement the same approach as you do, and I pick the same password as yours, then the hash will be the same. Rainbow tables win.

The way you fix that is with a static salt, not a modified hash function. You should pick a salt that represents your system. I usually like reverse DNS for this, because it leads to uniqueness. For example: "com.example.mygreatapp". Someone else would naturally pick "org.example.ourawesomedb". You also can pick a long random string, but the important thing is uniqueness, so I like reverse DNS. (Random strings tend to make people think the salt is a secret, and the salt is not a secret.)

That's the whole system; just pick some constant salt, unique to your system. (If you had a username, you'd add the username to the salt. This is a standard way to construct a deterministic salt.)

But for file storage, I'd never do it that way.