[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
