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  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]
Date: Thu, 13 Mar 2014 14:30:42 -0400
From: Patrick Mylund Nielsen <>
To: "" <>
Subject: Re: [PHC] "Why I Don't Recommend Scrypt"

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

>  On 3/13/14 10:31 AM, "Tony Arcieri" <> wrote:
>    On Thu, Mar 13, 2014 at 10:14 AM, Brian Matthews (brmatthe) <
>> 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
-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

Powered by blists - more mailing lists