in reply to
Adjust bcrypt cost to prevent future password hash attacks
Although I am not a crypto expert, my intuition is that this is a mis-application of the cost function. Instead of this, I suggest that the password should be stored as a salted hash-value. As you know, “salt” is a randomly-generated plaintext value, known to everyone because it is transmitted and stored with the hashed value, which has been in some way “mixed in” to the secret (the password) before the hash is computed. A four-digit salt provides 10,000 entirely different hash-values, all of which translate to the same unknown password. The odds are now 1 in 10,000 that Eve will even see the same hash twice if she taps into the communication circuit.
A successful attack on LinkedIn (or whomever) would depend upon that service storing the user passwords in the clear, so that they could be stolen as cleartext from the purloined database. But there is no plausible reason for storing a password “in the clear,” and it rather defies me why LinkedIn would actually have done so ... if indeed they did. (I frankly take news-stories that promise “total penetration and the recovery of plaintext card-numbers or passwords” with a grain of, ummm, salt.)
Hashing is useful simply for the validation of a secret, such that the secret remains unknown to the party who is validating it. The entire exchange over which the secret is transmitted should as a matter of course be encrypted, using a well-known and peer-reviewed “soup to nuts” protocol. I have no reason to believe that the usual suspects (SSL/TLS/VPN) would not be acceptable for any commercial-grade purpose. I am not a crypto expert. Your Mileage May Vary.™