Timing attacks are very difficult to pull off, but are possible nevertheless. However, it is quite easy to protect your Cake application against them, and as an aside – against incremental password crackers brute-forcing. This post shows you how.
What’s a timing attack?
A timing attack is when an attacker guesses your hashed password character by character, as opposed to using a dictionary or anything similar to try a brute force attack.
The way systems work is that your application hashes the password it receives from the user, and matches it to the hash it stores for this user in the users table.
This comparison stops at the first non-matching character. Therefore, it is possible to find your hashed value character by character, because the more correct characters you get – the longer the function takes to return. At least in theory.
What’s an incremental cracker brute force attack?
In an incremental crackin brute force attack, the attacker uses an incremental password cracker (e.g. John the Ripper) to feed your system a huge number of passwords – until it finds a good one.
While you may think that this takes time and effort – in reality these things rely on how responsive your web server is – so the faster your login code returns – the faster these tools will crack your user’s password (given a username, of course).
To this end, it makes sense to make your hashing algorithm as non-optimized as possible. This is nothing new, and has been out there for over a decade (look up ‘adaptive hashing’) but – most of these hashing algorithms, while they take their time – are at least consistent in the sense that they return their result consistently as well – therefore still rendering your system vulnerable to timing attacks.
The solution
The solution is only 2 lines added to the security.php file under cake/libs:
//In cake/libs/Security.php
.
.
function hash($string, $type = null, $salt = false) {
$_this =& Security::getInstance();
//introduce a random sleep
$sleep = mt_rand(); //1
usleep(($sleep%1000000)*3); //2
//original code continues
if ($salt) {
.
.
.
.
function hash($string, $type = null, $salt = false) {
$_this =& Security::getInstance();
//introduce a random sleep
$sleep = mt_rand(); //1
usleep(($sleep%1000000)*3); //2
//original code continues
if ($salt) {
.
.
The two lines above introduce a random wait time into your hash function.
line (1) generates a random number. The mt_rand function returns a number that can be quite large. Therefore, the usleep() method in line (2) uses its modulo 1,000,000 value, and multiplies it by 3, to introduce a sleep time of 0..almost 3 seconds. Since this is a pseudo-random number, it plays hide and seek with any timing-attack algorithm, but also delays incremental crackers enough to send them elsewhere.
The impact on your users should be minimal. They shouldn’t log on or log off more than once a session, and a mean time to wait of just over 1.5 seconds is not too bad in these scenarios.
Good luck!
Popularity: 3% [?]
If you enjoyed this article, please consider sharing it!
4 Responses to Protecting your cake site against timing attacks
Leave a Reply
Recent Comments
- paskuale: @Duck Ranger framework’s name: Yii (Yes it is)
- Hanzel: I’m having a hard time understanding why when i click “run as…” in the project it...
- paskuale: Great article, thanks to your article I realized the same thing but with another framework, I don’t...
- Radix: This indeed came first in google and saved heck lot of time for me. Thanks
- Aditya: Spot on!! Thank you!! Had no idea why this error was occurring.
- paskuale: @Duck Ranger framework’s name: Yii (Yes it is)
LinkedIn
Growing Kiwis
Growing Kiwis is my free service for early childhood education centers, preschools, daycares, kindies and more- any group of children, really.
Let me know what you think!
Thanks for this tip! I found adding this to the Security hash function slowed down every page request. Instead I added the same 2 lines to password function in the Auth component, just before the call to Security::hash.
Adding these two lines does not protect from said timing attacks. It only increases the number of samplings an attacker must make to determine the password. What you should be doing is using a constant time algorithm to compare said passwords in order to prevent the timing attack from working in the first place.
@Adler – I may have misunderstood what you were trying to say, but I think you are talking about a completely different thing.
Cheers
Is there a performance improvement involved in calculating the number of milliseconds to sleep yourself instead of letting mt_rand do that for you? Example:
@Adler: I suppose your scenario is to call the script a couple hundred times and record the timing, then take the median of those times? Would that really work on timing attacks? As far as I understand them, they rely on finding the needle in the haystack by trial an error. So the median would not help you recognise that certain value, as that special value might be much higher or lower as that median due to the sleep. Or am I missing something?