The easiest to understand example of this is bypassing a naive login prompt:

If the function to test a password that has been entered stops as soon as there is a wrong character, it's trivial to write a program to send it a modified password each run and see how long it takes to come back. If it takes slightly longer than last time, then you have one more character correct. Iterate until you have the complete password.

It's one cheesy thing that Hollywood does that at least worked at some point in the past, ie. the hacker that uses a program to crack a password one character at a time (preferably as the clock ticks down to some impending disaster)

Sorry for my skepticism, but even in old systems, wouldn't such a time would be too small to measure even by a program on the same computer? and I imagine that having a preemptive scheduler makes things even more complicated.

It's hard to imagine the attack you describe being viable.

You'll be surprised, but yes - it can be measured. Not even on same computer, but across different computers on Internet, even with all the random latency in the middle.

The idea is that you don't measure only once. You measure thousands, tens of thousands of times and more. Then any difference however small it will be also multiplied thousand times and it will be possible to measure it. Even if you will have other random processes such as OS scheduler, network latency, etc - it will be pretty obvious after thousands of measurements which ones to ignore. For example, check the histogram graphs in this paper: https://mlq.me/download/netspectre.pdf

My understanding of timing attacks is that they can be used when you can trigger the code path thousands of times quickly. This gives you execution time averages and distributions. Also, they're typically used against cryptographic hash functions which are more expensive than just a string compare.

https://en.wikipedia.org/wiki/Timing_attack

But if you use cryptographic hash functions, then you can't do the timing attack described because any one character change changes the whole hash.

Not for cracking a password perhaps, but imagine you have a system that looks at a MAC'd ciphertext. You want the system to attempt to decrypt a malicious ciphertext you've generated, but it won't until you have passed its MAC check.

With a timing attack, you can iterate the bytes of the MAC, itself probably based on a cryptographic hash like HMAC(sha256), until you get something that gets to the second stage.

You reduce MAC-forging complexity from 2 to the power of the number of MAC bits, to 256 times the number of bytes in the MAC.

Yup, that's why this attack doesn't really work on hash functions.

> It's hard to imagine the attack you describe being viable.

This has been the conventional thinking of software engineers for the past few decades. It turns out to be completely wrong.

I mean who would have thought measuring memory access latency could turn speculation into an arbitrary kernel read gadget yet here we are.

I once worked with a security researcher that would use infrared lasers to measure the temperature of different parts of a microcontroller to reverse engineer it. I have no idea what he did with that information but it blew my mind at the time.

Another example of a side-channel attack is guessing the text being typed on a keyboard by analyzing the sounds emitted from different keys: https://www.youtube.com/watch?v=2OjzI9m7W10