BCRYPT - Why not using it?
johhny_at_poland77
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????
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/12f2c1f59d1.48654546086297...@zoho.com
Ron Johnson
> 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.
--
"Neither the wisest constitution nor the wisest laws will secure
the liberty and happiness of a people whose manners are universally
corrupt."
Samuel Adams, essay in The Public Advertiser, 1749
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Aaron Toponce
> 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
Ron Johnson
[snip]
>
> 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
The OS must store the salt somewhere, in order to correctly authenticate
the user when he logs in. But I've never heard of /etc/hashsalt so what
am I misunderstanding?
--
"Neither the wisest constitution nor the wisest laws will secure
the liberty and happiness of a people whose manners are universally
corrupt."
Samuel Adams, essay in The Public Advertiser, 1749
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Boyd Stephen Smith Jr.
>On 04/06/2011 08:19 PM, Aaron Toponce wrote:
>> First, if you don't have the salt, but you do have the hash, then a
>> rainbow table attack is completely pointless.
>
>the user when he logs in. But I've never heard of /etc/hashsalt so what
>am I misunderstanding?
The value stored in /etc/shadow is both the salt + the encrypted
salt+password. This allows a process with read access to /etc/shadow to
easily read the shadow, encrypt the salt + provided password, and compare the
result to the encrypted salt+password. The salt is randomly generated each
time the password is set, and it (usually) different for each entry in
/etc/shadow.
This increases the size of a rainbow table by a factor of 2^(bits in salt),
effectively stopping the attack for all but the most high-profile target with
just an 8-bit salt. I'm not sure how many bits are used in a modern salt, but
I think it is somewhere between 48-bits and 64-bits.
Salted MD5 is still considered secure, even with the known attacks against
MD5. Salted SHA1 has no attacks more effective than brute-force. I'd like to
believe that shadow passwords will more to SHA3 within 2-3 releases after SHA3
is finalized. At the current rate of attack improvements against MD5, that
should be plenty of time.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Aaron Toponce
> The OS must store the salt somewhere, in order to correctly
> authenticate the user when he logs in. But I've never heard of
> /etc/hashsalt so what am I misunderstanding?
Yes, the salt and the password are both stored in the /etc/shadow file. If
you can read that file, then you have access to both. However, if you don't
have the salt but you do have the hash (maybe it's a different application
besides login you're attacking that stores the salt elsewhere), you don't
know the size of the salt, nor what was used in the salt to create the
hash. So, your search space has just expanded by 64^(number of characters
in salt).
For example, say you have the hash 633427ee13ba83a92778c91a795d444564b9214c
(which actually isn't the encoded format as shown in /etc/shadow, but it
will illustrate the point). You don't know what salt was used to create
that hash. It's 160 bits, so it could be SHA1. Assuming such, you send it
through a 7TB rainbow table, and turn up empty handed. So, either the
password is exceptionally strong, or it's using a salt, and could still be
strong, or could be weak. You don't know. And the only way to work it out
is start incrementing through salts for every string you try, up to some
reasonable point. I hope you have time on your hands, because you'll need
it.
In this case, the password was 'foo' and the salt was 'salt':
$ echo foosalt | sha1sum
633427ee13ba83a92778c91a795d444564b9214c -
Joel Roth
> In <4D9D1B22...@cox.net>, Ron Johnson wrote:
> >On 04/06/2011 08:19 PM, Aaron Toponce wrote:
> >> First, if you don't have the salt, but you do have the hash, then a
> >> rainbow table attack is completely pointless.
> >
> >The OS must store the salt somewhere, in order to correctly authenticate
> >the user when he logs in. But I've never heard of /etc/hashsalt so what
> >am I misunderstanding?
>
> The value stored in /etc/shadow is both the salt + the encrypted
> salt+password. This allows a process with read access to /etc/shadow to
> easily read the shadow, encrypt the salt + provided password, and compare the
> result to the encrypted salt+password. The salt is randomly generated each
> time the password is set, and it (usually) different for each entry in
> /etc/shadow.
So is the salt a fixed number of characters?
Otherwise, how would a process know which portion of the
string is the salt?
Regards,
--
Joel Roth
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110407043738.GA23159@sprite
Martin Ågren
> For example, say you have the hash 633427ee13ba83a92778c91a795d444564b9214c
> (which actually isn't the encoded format as shown in /etc/shadow, but it
> will illustrate the point). You don't know what salt was used to create
Of course, everything gets easier once you invoke Kerckhoff's
principle. This will give you both the algorithm and the salt, as the
only thing secret should be the password. :) Seriously though, all of
this information is likely found in the documentation in this case, or
in worst case in the source code. (Or in the leaked implementation in
the proprietary scenario.)
> In this case, the password was 'foo' and the salt was 'salt':
>
> $ echo foosalt | sha1sum
> 633427ee13ba83a92778c91a795d444564b9214c -
In this particular scheme, it appears ('foo','salt') has the same hash
as ('foosalt',''). In a serious application, hopefully the wheel
wouldn't be reinvented in this way, but some well-studied, thoroughly
scrutinized approach would be used. :) But as a toy example it works,
sure!
Take care,
Martin
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimigGOUBufY...@mail.gmail.com
Ron Johnson
> In<4D9D1B22...@cox.net>, Ron Johnson wrote:
>> On 04/06/2011 08:19 PM, Aaron Toponce wrote:
>>> First, if you don't have the salt, but you do have the hash, then a
>>> rainbow table attack is completely pointless.
>>
>> The OS must store the salt somewhere, in order to correctly authenticate
>> the user when he logs in. But I've never heard of /etc/hashsalt so what
>> am I misunderstanding?
>
> The value stored in /etc/shadow is both the salt + the encrypted
> salt+password. This allows a process with read access to /etc/shadow to
> easily read the shadow, encrypt the salt + provided password, and compare the
> result to the encrypted salt+password. The salt is randomly generated each
> time the password is set, and it (usually) different for each entry in
> /etc/shadow.
>
Is the salt just bits that are either pre- or suffixed to your password
before being run through the hashing function?
> This increases the size of a rainbow table by a factor of 2^(bits in salt),
> effectively stopping the attack for all but the most high-profile target with
> just an 8-bit salt. I'm not sure how many bits are used in a modern salt, but
> I think it is somewhere between 48-bits and 64-bits.
The first 3 characters of every hash in my /etc/shadow are the same.
That's what, 24 bits?
>
> Salted MD5 is still considered secure, even with the known attacks against
> MD5. Salted SHA1 has no attacks more effective than brute-force. I'd like to
> believe that shadow passwords will more to SHA3 within 2-3 releases after SHA3
> is finalized. At the current rate of attack improvements against MD5, that
> should be plenty of time.
But if you're machine is rooted then (besides having lots of other
problems) the attacker has your system-wide salt. (But the rainbow
table would still be unimaginably huge...)
--
"Neither the wisest constitution nor the wisest laws will secure
the liberty and happiness of a people whose manners are universally
corrupt."
Samuel Adams, essay in The Public Advertiser, 1749
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Martin Ågren
> The salt is randomly generated each
> time the password is set, and it (usually) different for each entry in
> /etc/shadow.
>
> This increases the size of a rainbow table by a factor of 2^(bits in salt),
> effectively stopping the attack for all but the most high-profile target with
> just an 8-bit salt. I'm not sure how many bits are used in a modern salt, but
> I think it is somewhere between 48-bits and 64-bits.
Practically speaking, the attacker prepares one table per hash, rather than
a huge table mixing different salts. When he gets the salt-and-digest, he
picks the correct table and gets running.
Obviously, for the same cost (pre-computation time, storage, online
time) as producing one table in the salt-less case, he can now
generate one table for one particular salt. So he either does it many
times, which becomes impractical, or he does it once for his
"favourite salt", e.g., one which often shows up in the wild due to
stupid/unlucky implementers using constant salt, bad random number
generators or whatever...
Or, when he gets 2^29 hashes from facebook, a salt size of 8 bits
would still give him about 2^21 hashes that he can run through his
table. (This scenario would have to count as "stupid implementers".)
Take care,
Martin
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikub1TANVxz...@mail.gmail.com
Aaron Toponce
> In this particular scheme, it appears ('foo','salt') has the same hash
> as ('foosalt',''). In a serious application, hopefully the wheel
> wouldn't be reinvented in this way, but some well-studied, thoroughly
> scrutinized approach would be used. :) But as a toy example it works,
> sure!
The point was to illustrate how a password and salt work to create a unique
hash. Sure, I could have covered all the details on the specific
/etc/shadow implementation, but then we wouldn't see the forest from the
trees.
At any event, point taken.
Aaron Toponce
> So is the salt a fixed number of characters?
From system to system, it varies. On my Fedora 14 virtual machine, it's 16
characters. On Debian 6.0 stable, it's 8.
> Otherwise, how would a process know which portion of the
> string is the salt?
You can read the shadow(5) manual on your Debian system to learn about the
syntax of the password. However, I'll give you the rundown:
The password is separated by '$'. Between the first and second '$' tells
the process what algorithm to use for the hash (MD5, SHA1, bcrypt, etc.).
Between the second and third '$' is the salt itself. After the third '$' is
the hash.
Aaron Toponce
> Is the salt just bits that are either pre- or suffixed to your
> password before being run through the hashing function?
The salt is generally appended to the password. For the specific case of
passwd(1), I'm not entirely sure, without looking at the source.
> The first 3 characters of every hash in my /etc/shadow are the same.
> That's what, 24 bits?
Thats.... interesting. Each salt is created at random. Combined with the
password string, it shuold produce a very unique hash. Because your hashes
all start with the same 3 characters, then you've been very lucky in the
output, due to the immense size of the keyspace.
> But if you're machine is rooted then (besides having lots of other
> problems) the attacker has your system-wide salt. (But the rainbow
> table would still be unimaginably huge...)
The salt is not system-wide, but local to the account. Each account will
have a unique salt, by default.
Aaron Toponce
> Having the first 3 characters all be "$6$" makes sense based upon
> the explanation in your other email. I thought that was the salt.
> Each user's salt is definitely different.
Ah, those first 3 characters. Yeah, that tells you that your hash is of the
SHA512 form. I thought you meant the first 3 characters of the hash itself.
$alg$salt$password is the form.
Ron Johnson
> On Wed, Apr 06, 2011 at 11:52:04PM -0500, Ron Johnson wrote:
>> Is the salt just bits that are either pre- or suffixed to your
>> password before being run through the hashing function?
>
> The salt is generally appended to the password. For the specific case of
> passwd(1), I'm not entirely sure, without looking at the source.
>
>> The first 3 characters of every hash in my /etc/shadow are the same.
>> That's what, 24 bits?
>
> Thats.... interesting. Each salt is created at random. Combined with the
> password string, it shuold produce a very unique hash. Because your hashes
> all start with the same 3 characters, then you've been very lucky in the
> output, due to the immense size of the keyspace.
>
Having the first 3 characters all be "$6$" makes sense based upon the
explanation in your other email. I thought that was the salt. Each
user's salt is definitely different.
--
"Neither the wisest constitution nor the wisest laws will secure
the liberty and happiness of a people whose manners are universally
corrupt."
Samuel Adams, essay in The Public Advertiser, 1749
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org