Re: [Cryptography] Why don't we protect passwords properly?

[Arnold Reinhold <agr@me.com>]

On  24 Dec 2013 19:03 Kriszti'n Pint'r wrote:
> Arnold Reinhold (at Tuesday, December 24, 2013, 6:21:29 AM):
> 
>> to substitute a better algorithm when it comes along. And is there
>> any cryptographer out there who knows the algorithm and believes
>> that scrypt could be weaker than PBKDF2? Seriously?
> 
> yep, plenty. for example all that knows the principle of not using
> branching/indexing on secret. pbkdf2 does not do that, and therefore
> safe against cache timing attacks. the same can not be said about
> either bcrypt, which uses secret based s-boxes, but especially not
> scrypt, which uses secret based memory access wildly.
> 
> one could also ask how safe it is to sprinkle the secret all over the
> RAM, increasing the risk of getting swapped to disc, or being
> recoverable by cold boot attack.
> 
> there is a lot to fear about scrypt. don't forget, we live in the era
> of side channel attacks. the safety of scrypt against direct attacks
> does not grant much in the real world.
> 
> to be totally safe, we would need a KDF that obeys all coding
> standards, runs in constant time, executes the exact same operations
> every time for every password, avoids using secret for indexing or
> branching, does not write secret to physical RAM, preferably keeps any
> secrets in the CPU, yet uses a large chunk of memory in a way that can
> not be optimized away.
> 
> i don't think we have any other option than capturing djb, and not
> letting him out of the basement until he comes up with a solution.

You forgot the most important criteria, parameterizable to not execute in parallel on modern GPUs. That is the threat today, not side channel attacks.  Scrypt can claim that, PBKDF2 can't.  I'm not aware of any side channel attacks on even individual stored passwords, much less mass attacks, but mass breaches of poorly protected stored passwords have become common, resulting large economic losses.

If you are really concerned about side channels, note that scrypt begins with a PBKDF2 call, so increasing its net iteration count to the typical levels in use today would provide the same protection against side channel attacks we now enjoy while thwarting the active problem of GPU attacks on purloined password hashes, including those by bots using thousands of consumer GPUs. 

I hope the current KDF competition comes up with better solutions, but that is no excuse for failing to provide strong protection for user passwords today using the technology we already have. As always, the best is the enemy of the good.

Arnold Reinhold