gmail security is a joke

Jimmy Hess mysidia at
Thu May 28 00:07:30 UTC 2015

On Wed, May 27, 2015 at 6:04 PM, Peter Beckman <beckman at> wrote:

> 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

More information about the NANOG mailing list