Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 24 Sep 2016 10:35:30 -0400
From: Scott Arciszewski <scott@...agonie.com>
To: passwords@...ts.openwall.com
Subject: Re: Blog Post about Password Resets

​Wow, I'm sorry, for some reason my grammar is terrible today. Let me try
again:

On Sat, Sep 24, 2016 at 7:03 AM, Alex Smirnoff <ark@...ex.net> wrote:

> Sorry, I did not get the idea.
>
> If you use the whole token's hash as both the selector and verifier,
> wouldn't
> it be easier just to make a verification function that works at a constant
> time?
> ​​
>

​Your database lookup, which is a search operation, cannot be relied
​ on​
to be constant-time.
​​


> (and aren't timing attacks already impactical even if you do not,
> because the attacker cannot manipulate arbitray bytes in the hash?)
>

Well, to begin with:
 Nobody else
​w
as prehashing the verifier.
​
​

W
​hat this means is they're doing
​th​
is:

​    ​
SELECT userid FROM reset_tokens WHERE token = ​'{$some
​AttackerProvided​
String}' AND expires < NOW()

...
​consequently,
 they're in a position to leverage any timing leaks that may exist in the
database software's search algorithm.

​Now, even if someone were to prehash with SHA256 to attempt to mitigate
this
​ timing leak​
, the output of SHA256 is deterministic.

You might not be able to manipulate the bytes, but you can create candidate
values that will leak timing information about the first N bytes of the
stored hash.
​ (You can precompute any SHA256 hash of any input you'd like.)​
Whether or not an attacker could leverage
​ a partial hash leak​
​
​
​
​
​
​
​
into a full exploit remains to be seen. It would remain an interesting
problem for attackers and defenders alike.

Using a split-token approach solves this problem by separating the
timing-leaky operation (the database lookup) from the constant-time
operation (the cryptographic verification). Even if you find a way to
reliably control one, you gain no information about the other. This design
decision totally stops timing leaks from being useful at all.
​ It's boring cryptography (the security critical operation is obviously
constant time, without caveats).​

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>​

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ