[180201] in North American Network Operators' Group
Re: gmail security is a joke
daemon@ATHENA.MIT.EDU (Jimmy Hess)
Wed May 27 20:10:42 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <alpine.BSF.2.00.1505271850140.99570@nog.angryox.com>
From: Jimmy Hess <mysidia@gmail.com>
Date: Wed, 27 May 2015 19:07:30 -0500
To: Peter Beckman <beckman@angryox.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Wed, May 27, 2015 at 6:04 PM, Peter Beckman <beckman@angryox.com> wrote:
[snip]
> I was thinking about using the last 2 digits of the year as the cost
> factor, but that might not scale with hardware linearly.
It is strongly recommended that when used for password storage, the
work factor for BCRYPT, SCRYPT, or PBKDF2 be hand-tuned based on the
current best available consumer desktop computing hardware.
Whenever it is manually adjusted; it should be tuned so that 1
password hash generation on a newly generated hash takes a minimum
500 milliseconds average at full throughput on the best current
generally available consumer hardware.
Or for an application where performance is more critical than
security.... no less than 100ms
on the server hardware.
Today; I believe the baseline would be a workstation with 4 5th
generation Intel i7 3.1GHz Quad-Core procs.
And I would suggest SCrypt() with a hefty selection for required
amount of RAM to compute the hash; in order to help foil attempts to
accelerate a hash-breaking process using GPU or FPGA technology.
> Bcrypt or PBKDF2 with random salts per password is really what anyone
> storing passwords should be using today.
>
> Beckman
--
-JH
