In Depth: Timing Attacks

[InDepth#6] You can use response timing to infer important information.

Greetings friends! I’m really excited about todays In Depth, as not only are we covering Timing Attacks, but since these are such a cool way to infer information from a webserver, I just had to put together a fun demo for you to play with (you’ll find the access details below). I’ve created a set of “User Enumeration” challenges, starting with trivial user enumeration, moving onto timing attacks, and finishing up with transliteration. Plus in addition to the demo site, I’ve also included a video of me working through the challenges, so you can see it in action¹. 😁

Before we move onto Timing Attacks, there are a few things I want to mention:
→ I now do Security Audits and Pentesting of Laravel apps. So if you’d like me to hack your app, and help you improve it’s security, please reach out! (I’ve got a slot open at the start of March if you want to get in quick.)
→ If you or anyone you know is thinking about getting a paid subscription, the 25% off Laracon discount will run out in a few days, so get that before it’s over. (You can also get the discount on Team Subscriptions).
With that out of the way, let’s get onto Timing Attacks…

---

Timing Attacks

As the name implies, a timing attack is an technique that uses timing to infer some knowledge that you shouldn’t normally have access to.

Since computers are fundamentally predictable, and everything about them is based off timing and available resources, we can glean a lot of knowledge by simply measuring how long it takes to complete a request.

If you’ve got kids you’ll be familiar with the “brush your teeth” dance we play each day: you ask them to go brush their teeth, they spend exactly 5 milliseconds in the bathroom, and then can’t understand why you know they haven’t brushed their teeth yet!
(My 5 year old hasn’t figured out he needs to wait a bit, while my 9 year old will go read a book or something and take even longer…)

We’ve talked about User Enumeration before, including common ways of hiding the existence of a valid email address, and it’s a good frame for discussing timing attacks, but they aren’t just limited to user enumeration. I’ll provide some more examples after we work through the process for password resets.

Password Resets

It’s typical for password resets to display a status message which either confirms the provided email address is valid, or displays an “unknown email” message. It is the default behaviour in Laravel, and in most cases it is a perfectly acceptable solution.

However, if you do need to prevent enumeration of email addresses through a forgotten password form, a common way to do so is to display the same message, regardless of the success of the request, in response to form submission. That way the user doesn’t know if the email address is valid or not.

Consider the difference between these two email addresses: