Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: Adjust bcrypt cost to prevent future password hash attacks

by sundialsvc4 (Monsignor)
on Jun 12, 2012 at 13:21 UTC ( #975802=note: print w/ replies, xml ) Need Help??


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.™


Comment on Re: Adjust bcrypt cost to prevent future password hash attacks
Re^2: Adjust bcrypt cost to prevent future password hash attacks
by Ransom (Beadle) on Jun 12, 2012 at 13:41 UTC

    The OP is using salted hashes and also assumes that LinkedIn was doing the same. The use of cost here would be to prevent many attacks per second against the hashes since an attack would take additional time. The hope is that this time is long enough to deter attackers who already have the ability to see your salted hashes, or have the ability to query the login server repeatedly. TLS has the ability to filter out login requests over the network, and this addition of bcrypt will help against physical attacks where data has already been compromised.

Re^2: Adjust bcrypt cost to prevent future password hash attacks
by Anonymous Monk on Jun 12, 2012 at 13:47 UTC

    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.

Re^2: Adjust bcrypt cost to prevent future password hash attacks
by chromatic (Archbishop) on Jun 12, 2012 at 17:35 UTC
    Although I am not a crypto expert, my intuition is...

    That would have been a good place to stop writing. The rest of your post is mostly irrelevant to the OP's question.

Re^2: Adjust bcrypt cost to prevent future password hash attacks
by andreas1234567 (Vicar) on Jun 12, 2012 at 18:52 UTC
    sundialsvc4,

    I regret to write that most of your three paragraphs make no sense at all. I mean no offense.

    --
    No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://975802]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (18)
As of 2014-07-14 15:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (267 votes), past polls