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.