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
signature.asc
Description: Digital signature
