It's using sha256, which is far too fast. Key stretching is essential, especially when something as fast as a digest function like the SHA family is used. PBKDF2, as the article points out, can be used to increase the cost of brute forcing, but bcrypt should be considered before opting for PBKDF + SHA.
An article [1] that appeared on HN last month (comments:[2]) also explains why just using hashing with a quick digest function is a bad idea, although this original article does a decent job of it (despite the author ignoring his/her own advice).
This article also uses built in equality tests for comparing the supplied hash to the stored hash. This is bad practice, as it is vulnerable to timing attacks. [1] covers this in the Extra section.
Yes. A GPU can calculate more than two billion SHA-256 hashes per second, and adding 32 random bytes to each hashing is not going to slow it down enough to matter. Salting protects against rainbow tables; it's not an effective protection against someone just trying to brute-force guess passwords.
This is true. The bruteforce attempts will include the salts in, simply adding to the length of the textdata being hashed. After they get the matching string to the hash, it's an easy enough process to then figure out which part is the password and which is the salt. Attempts to get around this are done by things such as:
SHA512 is obviously a bit most costly, and therefore harder to bruteforce, but if you truly care about security you would be best to use PBKDF2 at minimum (built into Django's standard).
I'm confused. That combination of SHA1 and MD5 is, itself, a hash function, and should be brute-forceable using the exact same methods you would use to brute force any other hash function. It's also easy to GPU-accelerate.
I believe that the original comment thought it was bad because the hashed password is stored alongside the salt. But, in practice this is never really a problem, because if they can get your hash, then the salt is usually always recoverable as well...
This is where some people think they are being clever. Because they think to themselves,
"hey, if I keep the salt secret and don't store the salt in the same table, or in the same field, then I've got awesome security by secrecy".
So all they do is hard code a salt that they reuuse for every hash in their application. Which offers them a lot less security overall for their users.
I have zero problem with storing the salt alongside the hashed password, because in practice, it doesn't make anything less secure.
You quoted me totally out of context (I don't use SHA and you are implying that I do. I didn't spot that in your original paste snippet, and clearly wrongly assumed that you were just referring to the concatenation of hash to salt.)
Nothing that I said was wrong (in fact it's sound advice), so I'm a little shocked at the massive downvotes, your blunt response, followed up with the patronising advice to rewrite all my software.
(And no, I don't use SHA. I didn't spot that in your snippet.)
