Bug 13286

On Wed, 12 Oct 2011, lsof at nodata dot co.uk wrote:

> Please could bcrypt support be added to glibc so that we have a modern, safe
> way of storing passwords?

What's wrong with the SHA-256 and SHA-512 based ways added in 2.7?

> Background and justification is here:
>  http://codahale.com/how-to-safely-store-a-password/

That says nothing about the SHA-256 and SHA-512 based methods.

> Summary of link:
>  Modern hardware can crack standard encrypted passwords very fast (even if they
> use a salt). bcrypt is a solution to this.

So are the methods added in 2.7.

http://www.akkadia.org/drepper/sha-crypt.html

(In reply to comment #1)
> What's wrong with the SHA-256 and SHA-512 based ways added in 2.7?

They're not designed for passwords, they're general purpose hashes.

> That says nothing about the SHA-256 and SHA-512 based methods.

I think it does. One of the headings is "Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}?"

> So are the methods added in 2.7.
> 
> http://www.akkadia.org/drepper/sha-crypt.html

The Coda Hale article says that salts aren't helpful for preventing dictionary attacks or brute force attacks.

The Drepper article is from 2007, before crazy-fast video card processing arrived for almost no money.

bcrypt is designed for secure password storage so the benefit to glibc would be increased security.

You haven't read the paper in detail, right?  You can tweak how expensive is it to compute it.
E.g.
crypt ("Hello, world!", "$6$rounds=99999999$asaltof16chars..")
takes almost 80 seconds to compute on pretty fast box these days, and the hashing scheme allows even 10 times more rounds than that.  While you can parallelize by computing crypt of many passwords at once, computing a single password is hardly parallelizable.
So if you are worried that you can crack it too fast, just use a higher rounds= from the default 5000.

(In reply to comment #3)
> You haven't read the paper in detail, right?  You can tweak how expensive is it
> to compute it.

I didn't read the paper, I just tried to answer your question by quoting the website that says that hash isn't very good for passwords.

> E.g.
> crypt ("Hello, world!", "$6$rounds=99999999$asaltof16chars..")
> takes almost 80 seconds to compute on pretty fast box these days, and the
> hashing scheme allows even 10 times more rounds than that.  While you can
> parallelize by computing crypt of many passwords at once, computing a single
> password is hardly parallelizable.
> So if you are worried that you can crack it too fast, just use a higher rounds=
> from the default 5000.

Okay so creating a crypted password is strong. I'm guessing the other types of attack (brute, dictionary, rainbow, etc.) are safe as well.

I'm not really the right person to be answering questions like this, I've e-mailed the author of the article, maybe he will reply here.

Onq question though - would it be a bad thing to have bcrypt as an option?

I added a long time back the new hash sum based password mechanisms.  They are at least as good.  I'm not going to add anything more.

(In reply to comment #0)
> Please could bcrypt support be added to glibc so that we have a modern, safe
> way of storing passwords?

The implementation you are talking about is already exists (since 1998).
It's called crypt_blowfish, you can find more information about it at
http://www.openwall.com/crypt/
Some GNU/Linux distributions integrated crypt_blowfish to their glibc packages long time ago, much before the moment of adding rival SHA-based algorithms to mainline glibc (about 4 years ago).

AFAIK the decision to not consider including bcrypt support to mainline glibc was a political one, so I very much doubt raising this issue in bugzilla could affect that decision.

*** This bug has been marked as a duplicate of bug 2100 ***