Bug 756586

Summary: Add support for Scrypt hash function for password authentication
Product: [Fedora] Fedora Reporter: Ben Segal <ben>
Component: glibcAssignee: Tomas Mraz <tmraz>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ben, fweimer, jakub, law, schwab, tmraz
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 756682 (view as bug list) Environment:
Last Closed: 2011-11-24 09:39:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Ben Segal 2011-11-24 00:16:16 UTC 
Modern GPUs are able to brute-force hashed passwords faster than ever, even when PBKDF2 or bcrypt are used. Scrypt (http://www.tarsnap.com/scrypt.html) is a key derivation function that is resistant to GPU-based attacks. I would like to see Fedora support the use of Scrypt password authentication. Please see the more detailed paper (http://www.tarsnap.com/scrypt/scrypt.pdf) on Scrypt for further details.
Comment 1 Tomas Mraz 2011-11-24 08:48:58 UTC 
The currently supported SHA256 and SHA512 hashed passwords allow choosing the iteration counts relatively freely.

If the scrypt should be supported in Fedora it would have to be included in the glibc crypt() implementation.
Comment 2 Ben Segal 2011-11-24 09:23:34 UTC 
Increasing the number of iterations can increase the time needed to compute a hash by a constant factor for both attackers with GPUs (or other specialized hardware) and ordinary users. Thus, the number of iterations necessary to make brute force attacks with GPUs unfeasible would also require ordinary users to wait a very long time for their CPUs to complete all of the hash iterations when using their passwords.

In contrast, Scrypt is designed such that hashes run relatively quickly on an ordinary user's CPU, but very slowly on GPUs used by potential brute-force attackers, forcing attackers to go back to brute-forcing with CPUs, and thus to surrender the advantage provided by GPUs for brute-forcing passwords hashed with current methods.

I apologize for filing this under the wrong component, however, and ask that it be looked at by the glibc team.