Bug 13286 - RFE: bcrypt support
Summary: RFE: bcrypt support
Status: RESOLVED DUPLICATE of bug 2100
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-12 17:52 IST by lsof
Modified: 2017-06-01 10:46 IST (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lsof 2011-10-12 17:52:36 IST
Please could bcrypt support be added to glibc so that we have a modern, safe way of storing passwords?

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

Summary of link:
 Modern hardware can crack standard encrypted passwords very fast (even if they use a salt). bcrypt is a solution to this.
Comment 1 joseph@codesourcery.com 2011-10-12 20:11:35 IST
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
Comment 2 lsof 2011-10-13 12:08:26 IST
(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.
Comment 3 Jakub Jelinek 2011-10-13 12:46:28 IST
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.
Comment 4 lsof 2011-10-13 19:49:56 IST
(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?
Comment 5 Ulrich Drepper 2011-10-15 13:37:36 IST
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.
Comment 6 Dmitry V. Levin 2011-10-16 18:48:31 IST
(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.
Comment 7 Dmitry V. Levin 2017-06-01 10:46:51 IST

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