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:30:01 -0400
From: Scott Arciszewski <scott@...agonie.com>
To: passwords@...ts.openwall.com
Subject: Re: Blog Post about Password Resets

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 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 has prehashing the verifier.
​
​

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

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

...which​ means 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, 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. Whether or
not an attacker could leverage this 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.

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