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.
> 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.
0: https://www.snellman.net/blog/archive/2016-07-27-ratas-hiera...
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.
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.
https://www.sjoerdlangkemper.nl/2024/05/29/string-comparison...
It makes sense that the packets return in an order that provides information, but we're talking about timing differences of a few ms; as tptacek says I would expect that there's some network jitter on the return path that has to be allowed for with timings this small?
Yet apparently not - obviously the attacks are working. Does he somehow know when the response left the server?
I am also a bit frightening that the number of attack you have to know for the Burp Certification keeps getting longer.
1) get username and password from user
2) check if username exists and if not, return error
3) if username exists, look up hashed password from db
4) hash potential password
5) compare actual and potential password. if same, generate token and return. else, return error
As you can imagine, we live in a universe with physical laws so steps 3-5 took time. That meant that you could blast login requests with any username and a known-bad password and compare the times it took to return the bad login error. If it was relatively quick, the username was bad. If it took longer than average, the username was good and the password was bad. Combine this with the freely available lists of common usernames and common passwords and one could start with nothing but the address of the login page and walk away with valid cred pairs. We ended up doing ip-based lockout after 10 failed login attempts and adding a random delay of 100-400ms before erroring out on a bad username.