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 <>
Subject: Re: Blog Post about Password Resets

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

On Sat, Sep 24, 2016 at 7:03 AM, Alex Smirnoff <> 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
as prehashing the verifier.

​hat this means is they're doing

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

 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
​ 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 <>​

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

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