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.
In reply to Re^2: Adjust bcrypt cost to prevent future password hash attacks
by Anonymous Monk
in thread Adjust bcrypt cost to prevent future password hash attacks
by andreas1234567
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |