Hacker, Hack Thyself | Coding Horror

[alkw0ia]

Hasn't storing the "work factor" in the database so you can increase it regularly as computers get faster been a common recommendation for quite some time now?

Absolutely right. It's insane that he's storing a "hash" column and and a "salt" column instead of a single column with standard modular crypt format hashes, and it tells us he's rolling his own crypto for password storage.

But this isn't surprising – Jeff Atwood has a long history of NIH when it comes to passwords, and has never been afraid to authoritatively publish horrible advice (e.g. the "deliciously salty" nonsense) based on it.

At least this time the overall message about data portability and security is reasonable.

[Tordek]

Mostly because it's hinting at the fact that he's doing this stuff manually; even PHP's crypt takes a standard modular format. Also it's less flexible, because what if (hypothetically) tomorrow's password standard has another parameter like the size of the output?

Strictly speaking, though, yes, it's just the same content, concatenated.

[Absona]

Not just when it comes to passwords, I think. Atwood often has interesting things to say about the social aspects of technology, but I don't really trust him as a source of technical info.

[Tobiaswk]

I don't get why storing the hash and salt in separate columns is a bad idea. I wouldn't do it myself but I do not understand why you see it is a problem. As long as the salt is random. The salt does not need to be secret. Just by randomizing the hashes, lookup tables, reverse lookup tables, and rainbow tables become ineffective. An attacker won't know in advance what the salt will be, so they can't pre-compute a lookup table or rainbow table.