public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jasa.david at gmail dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/16522] New: On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed Date: Mon, 03 Feb 2014 17:11:00 -0000 [thread overview] Message-ID: <bug-16522-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=16522 Bug ID: 16522 Summary: On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed Product: glibc Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: libc Assignee: unassigned at sourceware dot org Reporter: jasa.david at gmail dot com CC: drepper.fsp at gmail dot com When glibc encodes a password using sha256 or sha512 method and no indication of desired rounds is given (e.g. in login.defs or libuser.conf), the rounds count is set to 5000: https://sourceware.org/git/?p=glibc.git;a=blob;f=crypt/sha256-crypt.c#l86 https://sourceware.org/git/?p=glibc.git;a=blob;f=crypt/sha512-crypt.c#l86 This behaviour is getting suboptimal in light of recent rise hash-crunching on GPUs and dedicated chips (driven by cryptocurrencies mining but usable for password cracking as well). IMO glibc should employ similar approach to cryptsetup's: choose password hash computation time as long as possible without causing user inconvenience or DoS potential. For example, cryptsetup/LUKS uses 1 s: # cryptsetup --help ... Default PBKDF2 iteration time for LUKS: 1000 (ms) Which yields this theoretical and practical iteration count for on my 2010 machine: # cryptsetup benchmark ... PBKDF2-sha256 204161 iterations per second PBKDF2-sha512 134570 iterations per second # cryptsetup luksDump /dev/sda2 | grep -B1 Iterations Key Slot 0: ENABLED Iterations: 160803 -- Key Slot 1: ENABLED Iterations: 154588 In other words cryptsetup/LUKS with default settings gives about 30x better protection to user password than glibc with default settings. While glibc must take into account DoS scenarios that do not apply to cryptsetup (such as attacker trying to log in over as many ssh connections as possible), these considerations should result in shorter computation time (my guess: 500 ms instead of 1000) instead of choosing fixed rounds count that actually provides constantly decreasing security level. The most conservative approach wrt compatibility would be to take time to run password verification on 5% of slowest devices where glibc is deployed and use this (or a value within an order of magnitude), this way glibc behaviour on slow machines won't change while fast machines will get much better protection. The problem was spotted on glibc 2.18 (Fedora 20) but quick look to source code (above in the report) shows that git HEAD is still affected. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2014-02-03 17:11 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-03 17:11 jasa.david at gmail dot com [this message] 2014-02-03 17:50 ` [Bug libc/16522] " bressers at redhat dot com 2014-02-03 18:04 ` carlos at redhat dot com 2014-02-04 6:21 ` bugdal at aerifal dot cx 2014-02-04 15:26 ` jasa.david at gmail dot com 2014-02-04 19:14 ` bugdal at aerifal dot cx 2014-02-06 16:13 ` jasa.david at gmail dot com 2014-02-06 16:43 ` jasa.david at gmail dot com 2014-02-07 16:31 ` jasa.david at gmail dot com 2014-06-13 8:48 ` fweimer at redhat dot com 2015-07-05 17:32 ` rsawhill+sw at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-16522-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).