What is the most secure way to check that a given masterkey is valid? For the purposes of learning, I'm writing a small utility that allows encrypting a list of passwords using a single master key (using AES-256 and PBKDF2)

Before encrypting or decrypting any password user has to enter the master key (which will be used to derive a key for AES).

I would like to know what is the best option to know if a user has entered a valid master key : 


To salt and then hash the master key (once). The resulting salt and hash are stored somewhere - for instance in a DB. Later on, when the user has entered his master key, I add the stored salt and compare the computed hash with hash stored in DB.
To generate a salt. The salt is encrypted using the master key. I store both the salt and the encrypted salt in a DB. Later on, when the user enters the master key, I try to decrypt the encrypted salt value with the master key and compare it with the salt stored in DB.
Let call a user's Master Key for AES as $\mathit{MK}_u$ and generated as;

$$\mathit{MK}_u = \operatorname{PBKDF2}(\mathit{passwd}_u, \mathit{salt}, \mathit{Iteration})$$

where $\mathit{Iteration}$ between 40K to 100K


  1.  To salt and then hash the master key (once). The resulting salt and hash are stored somewhere - for instance in a DB. Later on, when the user has entered his master key, I add the stored salt and compare the computed hash with hash stored in DB.


$$\mathit{hashed} = \operatorname{SHA-256}(\mathit{salt} \mathbin\| \mathit{MK}_u)$$

A passive attacker can look at the DB and;


Password search on $\mathit{MK}_u$ with hashcat.


A better solution is also using; 


a pepper which is stored in the application server: this totally prevents the passive DB attacker
$$\mathit{hashed} = \operatorname{SHA-256}(\mathit{salt} \mathbin\| \mathit{MK}_u \mathbin\| \mathit{pepper})$$
Key-Stretching as PBKDF2 or Argon2: this also prevents and make it harder even pepper is accessed from the applications server.


$$\mathit{hashed} = \operatorname{PBKDF2}(\mathit{MK}_u, \mathit{salt} \mathbin\| \mathit{pepper}, \mathit{Iteration})$$


  2. To generate a salt. The salt is encrypted using the master key. I store both the salt and the encrypted salt in a DB. Later on, when the user enters the master key, I try to decrypt the encrypted salt value with the master key and compare it with the salt stored in DB.


$$\mathit{salt}_e = E_{\mathit{MK}_u}(\mathit{salt}),$$
and store $\mathit{salt}$ and $\mathit{salt}_e$ on DB.

For the second approach, the attacker can execute a password search for $\mathit{MK}_u$, this is almost the same as the attack shown against the #1 case since the attacker only deals with one AES encryption. To increase the iteration, one can modify this as in bcrypt.

The modified #2 approach is the winner due to the pepper in the passive DB attacker model.