Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 24 Sep 2016 10:46:48 -0400
From: Scott Arciszewski <>
Subject: Re: Blog Post about Password Resets

Sat, Sep 24, 2016 at 10:40 AM, Ark Arkenoi <> wrote:

> Given the tokens are relatively long and short-living, this kind of attack
> seems impractical. And the regular attacker has no direct access to
> database select function, he deals with an application wrapper which may be
> programmed to execute in a fixed time.
> Sent from my BlackBerry 10 smartphone.
> *From: *Scott Arciszewski
> *Sent: *Saturday, September 24, 2016 17:35
> *To: *
> *Reply To: *
> *Subject: *Re: [passwords] 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 <> 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 <>​
​This sounds dangerously similar to the notion of using a random delay to
prevent timing leaks, except maybe instead you're making sure it always
takes exactly N milliseconds to process.

See: and read the last sentence

You don't need to have direct access to the database for a timing
side-channel to exist or even be exploited. If you can control the input
that the application feeds into the database, and its search operation
involves variable-time string comparison (which is almost certainly the
case, since database searches are meant to be fast), you've got a timing

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.