Nadya already mentioned the problem of having a common password, but I think that's actually not such a big problem here, as you do some checks to make sure "123456" doesn't pass.

As I can see from "salty", you know that applying a hash function once or twice is not a good way to store a password (even in a hashed form).

Now, you're applying that hash function a lot more often than once or twice, but that still only takes a fraction of a second.

Quoting the "hashlib" documentation:

    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.

Your approach is not too tunable, in the sense that you can't configure its memory usage, only the time it takes.

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.

And then there is the well-known advice to not roll your own crypto. In this case, that means using a well-known key derivation function that's meant to be used in scenarios like this, instead of using your custom method with a "I think this is safe enough" attitude. Personally, I'd have a little more confidence in something that says "uses scrypt", simply because I know that name and that it's suitable for this application. It can still be used wrong, but I wouldn't feel compelled to check if you rolled something yourself. :)

Also check: http://security.stackexchange.com/questions/211/how-to-secur...

Lastly, I'm saying all this because I made one of these things myself, which used a dangerously custom method of seeding a "cryptographically strong" Sha1 PRNG for password generation. Yes, that bad.

If I said anything wrong, please correct me.