While reports vary, The Washington Post reported that the recent iCloud celebrity photo hacking centered around Find My iPhone's unprotected login point:
"...security researchers were said to have found a flaw in iCloud's Find My iPhone feature that didn't cut off brute-force attacks. Apple's statement ... suggests the company doesn't regard that revelation as a problem. And that's a problem, according to security researcher and Washington Post contributor Ashkan Soltani.
I agree. I wish Apple had been more forthcoming; its carefully worded response left room for different interpretations and seemed to blame the victims.
Hackers may have used this iBrute script on GitHub to target celebrity accounts via Find My iPhone; the vulnerability has since been closed.
Since one of the wealthiest corporations in the world didn't allocate the resources to rate limit all of their authentication points, it's likely that some of your web apps don't include rate limiting. In this tutorial, I'll walk through some of the basic concepts of rate limiting and a simple implementation for your PHP-based web application.
How Login Attacks Work
Research from prior hacks has exposed passwords that people tend to use most frequently. Xeno.net publishes a list of the top ten thousand passwords. Their chart below shows that the frequency of common passwords in their top 100 list is 40%, and the top 500 make up 71%. In other words, people commonly use and re-use a small number of passwords; in part, because they are easy to remember and easy to type.
That means that even a tiny dictionary attack using just the twenty-five most common passwords could be quite successful when targeting services.
Once a hacker identifies an entry point that allows unlimited login attempts, they can automate high speed, high volume dictionary attacks. If there's no rate limiting, then it becomes easy for hackers to attack with larger and larger dictionaries - or automated algorithms with infinite numbers of permutations.
Furthermore, if personal information about the victim is known e.g. their current partner or pet's name, a hacker can automate attacks of permutations of likely passwords. This is a common vulnerability for celebrities.
Approaches to Rate Limiting
To protect logins, there are a couple of approaches that I recommend as a baseline:
- Limit the number of failed attempts for a specific user name
- Limit the number of failed attempts by IP address
In both cases, we want to measure failed attempts during a specific window or windows of time e.g. 15 minutes and 24 hours.
One risk to blocking attempts by user name is that the actual user could get locked out of their account. So, we want to make sure we make it possible for the valid user to re-open their account and/or reset their password.
A risk to blocking attempts by IP address is that they are often shared by many people. For example, a university might host both the actual account holder and someone attempting to maliciously hack their account. Blocking an IP address may block the hacker as well as the actual user.
However, one cost to increased security is often a bit of increased inconvenience. You have to decide how strictly to rate limit your services and how easy you want to make it for users to re-open their accounts.
It can be useful to code a secret question into your app which can be used to re-authenticate a user whose account was blocked. Alternately, you can send a password reset to their email (hoping that it's not been compromised).
How to Code Rate Limiting
I've written a bit of code to show you how to rate limit your web applications; my examples are based in the Yii Framework for PHP. Most of the code is applicable to any PHP/MySQL application or framework.
The Failed Login Table
First, we need to create a MySQL table to store information from failed login attempts. The table should store the ip_address of the requesting user, the attempted username or email address used and a timestamp:
$this->createTable($this->tableName, array(
'id' => 'pk',
'ip_address' => 'string NOT NULL',
'username' => 'string NOT NULL',
'created_at' => 'TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP',
), $this->MySqlOptions);
Then, we create a model for the LoginFail table with several methods: add, check and purge.
Recording Failed Login Attempts
Whenever there is a failed login, we'll add a row to the LoginFail table:
public function add($username) {
// add a row to the failed login table with username and IP address
$failure = new LoginFail;
$failure->username = $username;
$failure->ip_address = $this->getUserIP();
$failure->created_at =new CDbExpression('NOW()');
$failure->save();
// whenever there is a failed login, purge older failure log
$this->purge();
}
For getUserIP(), I used this code from Stack Overflow.
We can also use the opportunity of a failed login, to purge the table of older records. I do this to prevent the verification checks from slowing down over time. Or, you can implement a purge operation in a background cron task every hour or every day:
public function purge($mins=120) {
// purge failed login entries older than $mins
$minutes_ago = (time() - (60*$mins)); // e.g. 120 minutes ago
$criteria=new CDbCriteria();
LoginFail::model()->older_than($minutes_ago)->applyScopes($criteria);
LoginFail::model()->deleteAll($criteria);
}
Checking for Failed Login Attempts
The Yii authentication module I'm using looks like this:
public function authenticate($attribute,$params)
{
if(!$this->hasErrors()) // we only want to authenticate when no input errors
{
$identity=new UserIdentity($this->username,$this->password);
$identity->authenticate();
if (LoginFail::model()->check($this->username)) {
$this->addError("username",UserModule::t("Account access is blocked, please contact support."));
} else {
switch($identity->errorCode)
{
case UserIdentity::ERROR_NONE:
$duration=$this->rememberMe ? Yii::app()->controller->module->rememberMeTime : 0;
Yii::app()->user->login($identity,$duration);
break;
case UserIdentity::ERROR_EMAIL_INVALID:
$this->addError("username",UserModule::t("Email is incorrect."));
LoginFail::model()->add($this->username);
break;
case UserIdentity::ERROR_USERNAME_INVALID:
$this->addError("username",UserModule::t("Username is incorrect."));
LoginFail::model()->add($this->username);
break;
case UserIdentity::ERROR_PASSWORD_INVALID:
$this->addError("password",UserModule::t("Password is incorrect."));
LoginFail::model()->add($this->username);
break;
case UserIdentity::ERROR_STATUS_NOTACTIV:
$this->addError("status",UserModule::t("You account is not activated."));
break;
case UserIdentity::ERROR_STATUS_BAN:
$this->addError("status",UserModule::t("You account is blocked."));
break;
}
}
}
}
Whenever my login code detects an error, I call the method to add details about it to the LoginFail table:
LoginFail::model()->add($this->username);
The verification section is here. This runs with every login attempt:
$identity->authenticate();
if (LoginFail::model()->check($this->username)) {
$this->addError("username",UserModule::t("Account access is blocked, please contact support."));
You can graft these functions on to your own code's login authentication section.
My verification check looks for a high volume of failed login attempts for the username in question and separately for the IP address being used:
public function check($username) {
// check if failed login threshold has been violated
// for username in last 15 minutes and last hour
// and for IP address in last 15 minutes and last hour
$has_error = false;
$minutes_ago = (time() - (60*15)); // 15 minutes ago
$hours_ago = (time() - (60*60)); // 1 hour ago
$user_ip = $this->getUserIP();
if (LoginFail::model()->since($minutes_ago)->username($username)->count()>=self::FAILS_USERNAME_QUARTER_HOUR) {
$has_error = true;
} else if (LoginFail::model()->since($minutes_ago)->ip_address($user_ip)->count()>=self::FAILS_IP_QUARTER_HOUR) {
$has_error = true;
} else if (LoginFail::model()->since($hours_ago)->username($username)->count()>=self::FAILS_USERNAME_HOUR) {
$has_error = true;
} else if (LoginFail::model()->since($hours_ago)->ip_address($user_ip)->count()>=self::FAILS_IP_HOUR) {
$has_error = true;
}
if ($has_error)
$this->add($username);
return $has_error;
}
I check rate limits for the last fifteen minutes as well as the last hour. In my example, I allow 3 failed login attempts per fifteen minutes and six per hour for any given username:
const FAILS_USERNAME_HOUR = 6; const FAILS_USERNAME_QUARTER_HOUR = 3; const FAILS_IP_HOUR = 24; const FAILS_IP_QUARTER_HOUR = 12;
Note that my verification checks use Yii's ActiveRecord named scopes to simplify the database query code:
// scope of rows since timestamp
public function since($tstamp=0)
{
$this->getDbCriteria()->mergeWith( array(
'condition'=>'(UNIX_TIMESTAMP(created_at)>'.$tstamp.')',
));
return $this;
}
// scope of rows before timestamp
public function older_than($tstamp=0)
{
$this->getDbCriteria()->mergeWith( array(
'condition'=>'(UNIX_TIMESTAMP(created_at)<'.$tstamp.')',
));
return $this;
}
public function username($username='')
{
$this->getDbCriteria()->mergeWith( array(
'condition'=>'(username="'.$username.'")',
));
return $this;
}
public function ip_address($ip_address='')
{
$this->getDbCriteria()->mergeWith( array(
'condition'=>'(ip_address="'.$ip_address.'")',
));
return $this;
}
I've tried to write these examples so that you can easily customize them. For example, you could leave out the checks for the last hour and rely on the last 15 minute interval. Alternatively, you could change the constants to set higher or lower thresholds for the number of logins per interval. You could also write much more sophisticated algorithms. It's up to you.
With this example, to improve performance, you may want to index the LoginFail table by username and separately by IP address.
My sample code doesn't actually change the status of accounts to blocked or provide functionality for unblocking specific accounts, I'll leave that up to you. If you do implement a blocking and resetting mechanism, you may want to offer functionality to separately block by IP address or by username.
I hope you've found this interesting and useful. Please feel free to post corrections, questions or comments below. I'd be especially interested in alternate approaches. You can also reach me on Twitter @reifman or email me directly.
Credits: iBrute preview photo via Heise Security
Comments