[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BCRYPT - Why not using it?

On Wed, Apr 06, 2011 at 06:18:45PM -0500, Ron Johnson wrote:
> On 04/06/2011 01:42 PM, johhny_at_poland77 wrote:
> >http://unix.stackexchange.com/questions/10326/does-openbsd-use-bcrypt-by-default
> >
> >Why doesn't every modern Linux Distribution use BCRYPT?
> >
> >http://codahale.com/how-to-safely-store-a-password/
> >
> >https://secure.wikimedia.org/wikipedia/en/wiki/Bcrypt
> >
> >WHY????
> >
> Just to piss you off.

That was the most helpful answer I think you could have given. Well done.

For this link: http://codahale.com/how-to-safely-store-a-password/, he is
clearly confused about many details of the hashed password stored in the
/etc/shadow file. Here are my issues with his article:

First, if you don't have the salt, but you do have the hash, then a rainbow
table attack is completely pointless. Reason being is rainbow tables store
hashes with a 1:1 ration to text. How the table is traversed is another
story, but the fact remains that one hash will lead you to one piece of
text. Now add a salt. If the salt is unknown, the length of the salt is
8 characters, and the characters used in the salt are [A-Za-z0-9./], or 64
characters, then there are effectively 64^8 possible hashes for one
password. That's 281474976710656 hashes. Even moving at 700,000,000
passwords per second, you have to generate that many hashes per password.
Point is, you have one massive keyspace to search through. Good luck.

Second, if the salt is known as well as the hash, then utilities like John
the Ripper can scream through a dictionary attack. I have access to a
cluster of 20 HP blades with 16 cores per blade. Running John the Ripper
can acheive a speed of 3.8 million passwords per second. .5% the claimed
speed in the article, but even then, I have not been able to crack a
password that contains 72-bits of entropy, that is not based on a
dictionary word, 1337 speak, or other silliness. It's been running for
almost 3 years on the same password. I'm just letting it go out of
curiosity to see if it will find it. I'm not hopeful it will before the
Death of the Universe. But, it's fun at any rate.

Lastly, the SHA1 and SHA2 algorithms were designed with security in mind.
Sure, they're fast, but that's the point. If you're concerned about
knocking a login prompt, you shouldn't be considering the speed of the
algorithm. Instead, you should be spending your time learning PAM. If
you're concerned about someone brute forcing an unshadow file, bcrypt isn't
going to help you if the password is low in entropy (he gives an example of
a 6-character password- seriously???). If your password is high in entropy,
as it should be, then even if SHA1 could churn through 400GBps, it's not
going to find it. Case in point, consider http://distributed.net hacking
the 72-bit RSA key. 72-bits of entropy, and it would take them 1,100 years
at their current rate to exhaust the keyspace entirely. That's only an
11-character password with [A-Za-z0-9] and [:punct:] as the possible
characters. 1,100 years for an 11-character password.

To get at your question though, bcrypt is supported in many GNU/Linux
operating systems. openSUSE used to default to bcrypt as their default
password hash for a long time (I don't know if they still do). Debian
GNU/Linux and GNU/kFreeBSD both ship bcrypt, although not installed by
default. Fedora also ships bcrypt out the gate.

So, to answer your question, most GNU/Linux operating systems support it.
It's only a matter of installing it and configuring PAM correctly.

. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o

Attachment: signature.asc
Description: Digital signature

Reply to: