phc-discussions - Re: [PHC] "Why I Don't Recommend Scrypt"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEw2jfzV8mytdwZ4OoE9S=Rmcz-aJW++qc5s8QmAqBJgEPn8PQ@mail.gmail.com>
Date: Thu, 13 Mar 2014 14:30:42 -0400
From: Patrick Mylund Nielsen <patrick@...rickmylund.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] "Why I Don't Recommend Scrypt"

On Thu, Mar 13, 2014 at 1:56 PM, Brian Matthews (brmatthe) <
brmatthe@...co.com> wrote:

>  On 3/13/14 10:31 AM, "Tony Arcieri" <bascule@...il.com> wrote:
>
>    On Thu, Mar 13, 2014 at 10:14 AM, Brian Matthews (brmatthe) <
> brmatthe@...co.com> wrote:
>
>>   A service I help run has had peak authentication rates of 1200/sec
>> [...] spread over 4 servers
>>
>
>  You have 1200 people *logging in* per second on 4 servers?
>
>
>  Oops, I was looking at the wrong stat, the peak is only about 400
> (today, it grows over time). It's not a classic login (like at a bank say),
> it's lighter weight, but it does require an authentication, so a password
> hash. And the servers don't have 400G either.
>
>  Brian
>

I think this is the closest to a good argument against expensive functions
that you get, but in my experience there's almost always a better solution.
It's fairly common that companies expose a REST API with some kind of
authentication, but still let users choose their own passwords for that API
(which is where things go wrong), and thus are forced to use stretching
functions that are called way more than they are in your typical
sign-in-and-set-an-authentication-cookie case. The real solution is to
offer API keys with sufficient randomness that stretching isn't
necessary--it's infeasible to reverse a single HMAC-SHA256--not to
compromise on the security of your password digests.

Content of type "text/html" skipped