Argon2 for both password storage and key derivation Is using Argon2 for both password storage and key derivation secure? I'm planning on using different salt values, of course.

The basic concept is something like this:

Alice has some secret data ($data_e$) on her account. It's encrypted with an Argon2 derived key from her password, using a random salt.

$$ k = \operatorname{Argon2}(\text{password}, \text{salt}_1, \text{iteration})$$
$$ \text{data}_e = \operatorname{E}_k(\text{data})$$

Alice's password is stored as an Argon2 derived key from her password, using a random salt. When Alice (or an adversary) wants to log in, a key is derived from the input using Alice's password salt and checked for a match.

$$\text{storedPWD} = \operatorname{Argon2}(\text{password}, \text{salt}_2, \text{iteration})$$


Should the secret data be encrypted with Alice's raw password?
Should her data to be encrypted with a random key encrypted with her raw password? With a key derived from her password?


You should assume that Alice is a trained system administrator who understands the risk of having a weak password. The password will have at least 12 characters, will include capital and small letters and have numbers.

Also assume that the login system is bruteforce-resistant, but think about the possibility of a database breach.

Thanks in advance.
Should the secret data be encrypted with Alice's raw password?


As a general rule of thumb:
A password should only ever be fed into a password hashing scheme (PHS) such as Argon2, scrypt or bcrypt, never into anything else!

There are multiple reasons for this:


Passwords need special processing in the form of complexity parameters.
Passwords need external (high-entropy) sources of uniqueness / randomness to be mixed in.
Passwords should be allowed to be long and variable-length, most cryptographic primitives have very specific expectations on key lengths.
Passwords usually aren't randomly uniformly distributed bit strings (eg the highest bit is rarely set), which most encryption algorithms assume for their keys.



  Should her data to be encrypted with a random key encrypted with [...] a key derived from her password?


Yes. Another good rule of thumb is:
Only ever perform one password hashing per user, but give it all the resources you can spare.

The idea behind this is:


If you chain derivations and an attacker can validate whether they got the correct value for an intermediate stage, they only need to compute the last stages once, instead of once for all passwords.
If you don't expose intermediate values, you effectively created a new composite hashing scheme.
If you perform two independent derivations, you are likely to lower the resources required for each individual one and it is sufficient for the adversary to only break the weakest one and get the other one(s) "for free".




The rest is similar to smrt28's answer:

Encrypting a high-entropy key with a password-derived key allows your users to change the password without you having to re-encrypt the entire data, which may be costly in terms of CPU-time and I/O-time if you have a lot of data.

Additionally, if you use authenticated encryption (AE) using the derived key for the high-entropy key, you essentially get secure password confirmation "for free", as the scheme will very clearly report an error if the password and thus the derived key is wrong. Additionally, you can cryptographically bind derivation parameters like salt and iteration count to successful decryption using the associated data input of most AE schemes.
So in formulas: $\text{derKey} = \operatorname{Argon2}(\text{password}, \text{salt}, \text{iteration}), c=\operatorname{AE}_{\text{derKey}}(\text{MK})$ and now if one tries to decrypt with the wrong password, the AE-scheme will report an authentication failure as the key is wrong and if it is right, it will just return the correct master-key.