Nadya already mentioned the problem of having a common password, but I think that&#x27;s actually not such a big problem here, as you do some checks to make sure &quot;123456&quot; doesn&#x27;t pass.<p>As I can see from &quot;salty&quot;, you know that applying a hash function once or twice is not a good way to <i>store a password</i> (even in a hashed form).<p>Now, you&#x27;re applying that hash function a lot more often than once or twice, but that still only takes a fraction of a second.<p>Quoting the &quot;hashlib&quot; documentation:<p><pre><code>    Key derivation and key stretching algorithms are
    designed for secure password hashing. Naive algorithms
    such as sha1(password) are not resistant against
    brute-force attacks. A good password hashing function
    must be tunable, slow, and include a salt.
</code></pre>
Your approach is not too tunable, in the sense that you can&#x27;t configure its memory usage, only the time it takes.<p>What if your attacker just throws more money at the problem? Sha256 has been shown to be feasible to implement in hardware, and that fraction of a second will melt away, partly possible because not much memory is consumed.<p>And then there is the well-known advice to not <i>roll your own crypto</i>. In this case, that means using a well-known key derivation function that&#x27;s meant to be used in scenarios like this, instead of using your custom method with a &quot;I think this is safe enough&quot; attitude. Personally, I&#x27;d have a little more confidence in something that says &quot;uses scrypt&quot;, simply because I know that name and that it&#x27;s suitable for this application. It can still be used wrong, but I wouldn&#x27;t feel compelled to check if you rolled something yourself. :)<p>Also check: <a href="http:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;211&#x2F;how-to-securely-hash-passwords&#x2F;31846#31846" rel="nofollow">http:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;211&#x2F;how-to-secur...</a><p>Lastly, I&#x27;m saying all this because I made one of these things myself, which used a dangerously custom method of seeding a &quot;cryptographically strong&quot; Sha1 PRNG for password generation. Yes, that bad.<p>If I said anything wrong, please correct me.