[archi42]

I was told it's best practice these days to hash several times: If you hash the $salt.$pw string several hundred times (e.g. 512 or 65536) that only takes a few ms on you server (each time), but for a cracker the constant factor is rather painful, even if only probing simple passwords.

//edit: not sure bcrypt does NOT do this by default.

[Someone1234]

You were told by who?

That's bad advice. BCrypt and pbkdf2 have a work-factor that accomplishes the same thing built in. The work-factor is added to the start of the resultant hash allowing different work-factors to be intermingled. This allows you to scale your work factor up over time as hardware power increases (or to mitigate weaknesses found in the underlying algorithm).

So, no, don't hack your own version of the work-factor instead of using bcrypt's solution. Your hack-version won't be standard compliant (between different BCrypt libs) or self-documenting. It also isn't increasing security, but is adding more potential sources of bugs.

[beatgammit]

bcrypt also does salting by default for you as well. It's really not difficult, just use a decent library.

[jammygit]

What does it mean to do salting by default?

[archi42]

The guy who is called after it's too late (he's a friend, I didn't call ;-)).

So it's bad advice to use a work factor and instead you recommend using a work factor? Uh yeah, still thanks for pointing out how that's called I guess? To clarify: I didn't say one should roll his own hashing, I just described the process; I simply don't assume the average HN reader to be an idiot and already use bcrypt or similar.

Edit: forgot to mention, parent comment also roughly described what his bcrypt is doing.

[jjeaff]

In addition, it's a good idea to run a test on your hardware with bcrypt and increase the work factor until it takes just enough time to still be comfortably fast. You don't want it to take 10 seconds to solve. But you also don't want 10ms.