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

Sat, Sep 24, 2016 at 10:40 AM, Ark Arkenoi <ark@...ex.net> 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: *passwords@...ts.openwall.com
> *Reply To: *passwords@...ts.openwall.com
> *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 <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/>​
>
>
​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: http://stackoverflow.com/a/28486617/2224584 and read the last sentence
too.

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
leak.

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