Re^2: Adjust bcrypt cost to prevent future password hash attacks

[Anonymous Monk]

Linkedin practically stored the user passwords in the clear. They stored them as unsalted SHA1 hashes. The vast majority of them can be cracked by having a rainbow table, i.e. a precomputed table of SHA1 hashes of common and less common passwords.

I believe the OP is worried that the attacker might gain access to the password database (or even a single password hash) and then start cracking that offline. This is where attacks are their most potent.

Having a costly crypto function is meant to thwart password-guessing attacks, especially brute force ones. Pretty much every OS uses these for password checking. Bcrypt takes the cost idea a bit further and gives adaptable cost, doubling in computation length for every step, to cover for future increases in CPU speed.

Oh, and I'm not a crypto expert either.