Bug 16814

Summary:	RFE: Reconsider adding bcrypt (or scrypt) support
Product:	glibc	Reporter:	sf
Component:	crypt	Assignee:	Not yet assigned to anyone <unassigned>
Status:	NEW ---
Severity:	enhancement	CC:	bugdal, dkg, dominik.mierzejewski, drepper.fsp, fweimer, rsawhill+sw, thepouar
Priority:	P2	Flags:	fweimer: security-
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

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:

https://sourceware.org/ml/libc-alpha/2018-05/msg00690.html

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