7 ms·
There are so many of these. I don't discourage building one for fun, but they're usually not practical. The common problems are password resets, different pass
by tilpner 11y ago
There are so many of these. I don't discourage building one for fun, but they're usually not practical.
The common problems are password resets, different password restrictions/formats, and the need to remember these.
Also... Sha256 for password generation? I've been told that's wrong™, even if you do it a lot of times, and was pointed at key derivation functions like scrypt, bcrypt, etc.
- libeclipse 11y agoWhy is it wrong?
- tilpner 11y agoI'd embarass myself if I tried to explain this with the correct terms, so I won't try. One of those articles, but there may be better or more correct ones: http://www.justgohome.co.uk/blog/2014/02/salting-hashing-and-key-derivation.html http://www.justgohome.co.uk/blog/2014/02/salting-hashing-and...
- libeclipse 11y agoVisionary doesn't try to store passwords securely. I'm not sure how that article is relevant, but maybe I'm missing something. Care to elaborate?
- tilpner 11y agoNadya 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-securely-hash-passwords/31846#31846 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.
- libeclipse 11y agoThanks for the constructive feedback mate. I'm considering implementing pbkdf2 and using that instead of sha256. Thoughts?
- libeclipse 11y agoActually I think I'm going to go with Scrypt. Just looking at my key generation code now, and it looks childish and terrible.