Date: Mon, 11 Jun 2012 19:24:23 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: "Simon L. B. Nielsen" <simon@FreeBSD.org> Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= <des@des.no>, Lev Serebryakov <lev@freebsd.org>, freebsd-security@freebsd.org Subject: Re: Default password hash Message-ID: <20120611162423.GA27001@reks> In-Reply-To: <CAC8HS2EKQTWSE%2BtD5Y68E6YRiJjjogSEgXPBeqDH3b-cO_-DAQ@mail.gmail.com> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <734419687.20120611144402@serebryakov.spb.ru> <CAC8HS2EKQTWSE%2BtD5Y68E6YRiJjjogSEgXPBeqDH3b-cO_-DAQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (11/06/2012 12:51), Simon L. B. Nielsen wrote: > On Mon, Jun 11, 2012 at 11:44 AM, Lev Serebryakov <lev@freebsd.org> wrote: > > Hello, Simon. > > You wrote 10 июня 2012 г., 14:02:50: > > > > SLBN> Has anyone looked at how long the SHA512 password hashing > > SLBN> actually takes on modern computers? > > Modern computers are not what should you afraid. Modern GPUs are. > > And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2. > > > > Modern key-derivation schemes must be RAM-heavy, not CPU-heavy. > > But the modern CPU's will limit the number of rounds you can use for a > hash (if you use same system as md5crypt), as you can't let users wait > 10+ seconds to check their password. > > > And I don't understand, why should we use our home-grown > > "strengthening" algorithms instead of "standard" choices: PBKDF2[1], > > bcrypt[2] and (my favorite) scrypt[3]. > > Recall that FreeBSD's MD5 strengthening probably predates most of the > other systems by a while (I'm too lazy to look it up). > > That said, I generally agree we should go with something standard or > existing unless there is a very good reason not to. > > PBKDF2 / RFC2898 is what GELI uses (which I mentioned previously). PBKDF2 as a key derivation function is a bit different from a key stretching concept. KDF's *main* goal is to produce cryptographically good keys, but not to make bruteforce attacks hard on GPU/FPGA/etc. As already mentioned, nowadays good key stretching algorithms are supposed to be GPU-unfriendly. That is the case with crypto_blowfush, crypt_md5 and crypt_sha* thanks to data dependent branching, but it's not true for PBKDF2. I suppose everybody reading this thread has already seen recent presentation by Solar Designer on password security (video should also be available online): http://www.openwall.com/presentations/PHDays2012-Password-Security/ What particularly interesting is the following slide, comparing crypt_sha512/crypt_blowfish GPU-friendliness and performance: http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00037.html In other words, currently there is no benefit in switch default algorithm to relatively new crypt_sha512 vs 256-iterations crypt_blowfish supported on RELENG_7. crypt-md5.c except: for(i = 0; i < 1000; i++) { MD5Init(&ctx1); if(i & 1) MD5Update(&ctx1, (const u_char *)pw, strlen(pw)); else MD5Update(&ctx1, (const u_char *)final, MD5_SIZE); if(i % 3) MD5Update(&ctx1, (const u_char *)sp, (u_int)sl); if(i % 7) MD5Update(&ctx1, (const u_char *)pw, strlen(pw)); if(i & 1) MD5Update(&ctx1, (const u_char *)final, MD5_SIZE); else MD5Update(&ctx1, (const u_char *)pw, strlen(pw)); MD5Final(final, &ctx1); } > > [1] http://tools.ietf.org/html/rfc2898 > > [2] http://static.usenix.org/events/usenix99/provos/provos_html/node1.html > > [3] http://www.tarsnap.com/scrypt.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120611162423.GA27001>