Bug 16814 - RFE: Reconsider adding bcrypt (or scrypt) support
Summary: RFE: Reconsider adding bcrypt (or scrypt) support
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: crypt (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-04-06 17:57 UTC by sf
Modified: 2018-05-24 14:25 UTC (History)
6 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description sf 2014-04-06 17:57:48 UTC
I know that there has been a previous request for bcrypt support in crypt(3) [1] which has been refued. But I want to ask you to reconsider. The sha-crypt algorithms supported by glibc today have the problem that using a GPU speeds up brute forcing significantly. See e.g. [2]

This is especially a problem when using password hashing in situations where the work factor (the number of rounds) cannot be increased arbitrarily:

1) on low power systems (think ARM, Atom)
2) in situations where lots of hashing operations have to be done per second. For example on web servers for basic authentication, where the check needs to be done for every request.

Also, adding bcrypt support to glibc improves interopability in heterogeneous environments where accounts are distributed on many machines automatically. There are OSs that support bcrypt but not sha-crypt. Those OSs (rightly) don't like to add support a less secure scheme for the sake of interopability.

Of course, one could also argue for support for scrypt. It has some advantages over bcrypt against FPGA-based attacks. But scrypt requires >1MB RAM to defend as good against GPU-based brute forcing, and that makes its use in the webserver scenario somewhat problematic.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=13286
[2] http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/mgp00042.html
Comment 1 Rich Felker 2015-11-20 03:06:14 UTC
I'd like to propose we break this up into two parts:

1. bcrypt: this is trivial to add internally in glibc and should just be added.

2. scrypt, Argon2 (PHC winner), and anything else "heavy": it's unreasonable to expect to be able to allocate many MB (or even GB) in the calling application's address space to hash a password. It would also be desirable to be able to support new hashes without waiting for glibc to add support for them. So what I propose is that, for setting strings glibc doesn't recognize internally, it should connect via a unix socket to a password hashing daemon which will do the actual work and pass back the result. If there's interest in this idea I would be happy to help with the design for the protocol support on the glibc side.
Comment 2 Daniel Kahn Gillmor 2018-05-24 14:12:05 UTC
Rich, your suggestion for the password-hashing daemon is pretty interesting, but i'm not sure how you'd control/ration/audit access to it.  it strikes me as a relatively easy DoS vector for the machine as a whole, if the hashing is done by a dedicated user account, which isn't tied directly back to any of the other accounting systems.

fwiw, i agree that we should have something better than the sha-2-based digests available.  I'm not entirely sure why we should avoid heavyweight memory/cpu access for those applications which need to hash passwords, though.  if you need to hash passwords responsibly, you need to do some work.  most tools don't do password-hashing, so we're not talking about adding this to arbitrary systems.
Comment 3 Florian Weimer 2018-05-24 14:25:57 UTC
We are going to support building glibc for use with an external libcrypt.  Zack Weinberg has posted patches:


The external libcrypt can then implement whatever policies it wants, and develop at a pace that is independent from glibc.