Timing Attacks are really interesting, and they can be leveraged to break your password … just hear me out.
Of course, passwords are not stored as plain text, but rather they are hashed and stored. Now, during authentication, the password (provided by the user) is hashed and compared against what is stored in the database. The exploitation happens when these hash digests are compared.
A simple way to test if the password hash matches or not is by using the standard == operator. Timing attacks exploit the way strings are compared, and this is where things get interesting.
Most programming languages implement string comparison by checking character-by-character and returning False immediately when they find a mismatch. This means:
- correct first character but wrong second: ~2 CPU cycles
- correct first 10 characters but wrong 11th: ~11 CPU cycles
- completely wrong password: ~1 CPU cycle
Attackers exploit this timing difference to guess passwords in two phases. First is length discovery, where they try passwords of different lengths and measure response times to determine the correct password length.
Once the length is known, they apply brute force and try each character position systematically and using timing to determine when they guessed correctly.
This isn’t theoretical; timing attacks have been demonstrated in web applications over a network (even with jitters) and hardware devices.
So, what’s the solution? The solution is to use a constant-time comparison functions that always take the same amount of time regardless of where differences occur - something like hmac.compare_digest.
Now tell me, engineering is not fun :)