Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ miki123211 5 days ago

Timing attacks are such a pernicious idea.

You look at the code and see that there's an auth check in place, you test the code to verify that the auth check has no bugs, you make sure that information is never shared with people who don't have authorization to access it, and yet it turns out it can be accessed as if there was no auth check at all.

To make matters worse, everything can be fine for some time, and then some clever optimization in the CPU, the compiler, cache layer or the database engine introduces a completely unexpected side channel.

▲emilfihlman 4 days ago | parent | next [-]

Fortunately a quick fix is to first go through a cryptographically secure trapdoor function that makes the initial check security time invariant, like with sha256 with a random salt, before checking exact byte matching.

▲tptacek 4 days ago | parent [-]

This is an old (and unpopular) countermeasure for simple string timing attacks, but that's not what this article is talking about and that countermeasure isn't reasonable in most of the cases Kettle is talking about.

▲GoToRO 5 days ago | parent | prev [-]

would adding random delays prevent this?

▲pwagland 5 days ago | parent | next [-]

No, it only makes it take longer to get the underlying secret.

Timing attacks are already dealing with "noisy" data, task scheduling et al, so they all boil down to some level of statistical analysis on the response times. Adding noise to that slows you down, but the underlying bias on the timings is still there.

▲ozim 4 days ago | parent | next [-]

So in practice it prevents the attack as real world attackers have limited resources and try to find easier targets.

▲saagarjha 4 days ago | parent [-]

That’s what everyone says until they realize they understated the costs to attempt such an attack.

▲ozim 2 hours ago | parent [-]

That's true if you host wordpress or joomla or something that is widely used that would have timing attack, because then someone will automate it for sure.

If you have your custom web app I don't think anyone will bother unless you are bank or something.

▲GoblinSlayer 4 days ago | parent | prev [-]

So you need to compute this statistics and add just the right delay to even out the bias.

▲saagarjha 4 days ago | parent [-]

At that point you’ve implemented a constant-time algorithm.

▲Alex-Programs 4 days ago | parent | next [-]

It works quite well in practice though. I wonder if you could make an ergonomic library for it.

Just add a macro to a function and it'll keep track of how long past executions took to execute and add artificial delays to ensure all subsequent executions are at least that long. If they're longer, extend the minimum time by 2x.

Perhaps apply an AIMD algorithm to it? Though there's still room for exploitation there, it'd just take a lot longer to find. Just letting the programmer specify the minimum time might be better in practice.

▲endofreach 4 days ago | parent [-]

Good luck explaining CEO / PM you need slower response times.

▲dotancohen 2 days ago | parent [-]

"It's a security measure" would be a very convincing line for a slower response time on a single, infrequent action that the user takes.

▲GoblinSlayer 4 days ago | parent | prev [-]

It can be implemented once, by, say, nginx and enabled by a devops instead of every random outsourced java webapp.

▲Filligree 5 days ago | parent | prev | next [-]

Random delays specifically do not, as they average out. Delays until a specific point in time do work, so long as the delay is never negative.

▲bostik 4 days ago | parent [-]

This particular case would be a fantastic fit for timer wheel.[0] Instead of writing a brittle implementation of "after a fixed time in the future" logic yourself, you queue the outgoing event to occur after N ticks [of granularity X], and let the dedicated data structure engine do the work for you.

0: https://www.snellman.net/blog/archive/2016-07-27-ratas-hiera...

▲wiredfool 5 days ago | parent | prev | next [-]

One thing that I’ve done where I previously had a random delay is implement a delay till a constant time from the start of the request. So all of the timing you get out is effectively how well sleep can target a time.

▲tptacek 5 days ago | parent | prev | next [-]

It depends on the kinds of attacks you're thinking of. For the stuff Kettle is doing, probably yes. For cryptographic side channels, probably no.

▲jack_pp 5 days ago | parent | prev [-]

or you could benchmark the functions that compare secrets to user input and figure out how much time it's supposed to take, add 0.5s to the average and always add time before responding to get to that target so essentially your response time is constant regardless of input

▲tptacek 5 days ago | parent [-]

Important to keep in mind here that the timing attacks Kettle is talking about generally do not take the form of "providing secret input to a function with variable timing".

▲jack_pp 4 days ago | parent [-]

He says this exact same thing in the Defense at the end:

> Finally, yes I do recommend using constant-time functions when comparing user input with secret keys. Just ask anyone who says this is an actual threat to provide a proof of concept.