Re: Adjust bcrypt cost to prevent future password hash attacks

Replies are listed 'Best First'.
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.	[reply]
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]	[reply]
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.	[reply]
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.	[reply]


go ahead... be a heretic
	PerlMonks