Instead of rolling your own, you should use PBKDF2, which does what you try, but right. Alternatively use scrypt or maybe bcrypt, they try to be more expensive on GPUs and custom cracking hardware.
(this will take about a million times longer compared to the usual method of calling a single hash function)
If you used $n=10^9$, brute force would take a billion times as long. However, that would be really slow to use in practice. My mid range Intel CPU can hash ~10 million SHA-256 / s on one core, meaning a couple of minutes for your $n$. A million is more reasonable.
Does it make sense to store them in the following form instead:?
Your iterated hash has some weaknesses compared to PBKDF2.
- Each iteration increases the collision rate. If you use a large enough hash function with $\log_2n$ bits of collision resistance to spare, that will not matter in practice, but PBKDF2 avoids it.
- By using HMAC, PBKDF2 benefits from security proofs that show it is potentially secure (pdf) with some hash functions with which yours is not. Also a theoretical thing unless you use an obsolete/broken hash.