←back to thread

Listen to the whispers: web timing attacks that work

(portswigger.net)
178 points saikatsg | 3 comments | 21 Nov 24 18:08 UTC | HN request time: 0s | source
Show context
miki123211 ◴[21 Nov 24 20:08 UTC] No.42208092[source]▶
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.

replies(2): >>42208294 #>>42214191 #
GoToRO ◴[21 Nov 24 20:29 UTC] No.42208294[source]▶
would adding random delays prevent this?
replies(5): >>42208493 #>>42208931 #>>42208951 #>>42208997 #>>42209530 #
1. jack_pp ◴[21 Nov 24 21:40 UTC] No.42208951[source]▶
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
replies(1): >>42209246 #
2. tptacek ◴[21 Nov 24 22:15 UTC] No.42209246[source]▶
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".
replies(1): >>42211707 #
3. jack_pp ◴[22 Nov 24 06:58 UTC] No.42211707[source]▶
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.