In a perfect world, we’d all have strong and different passwords for every site we visit.We know it’s the right thing to do. But then again, we also know that getting regular exercise is the right thing to do. And maybe, just maybe, we don’t always get around to doing the “right” things.
Today, there are just so many sites out there and coming up with umpteen different passwords isn’t always easy for people. Password reuse is rampant, even among people who should know better and creates a vulnerability that can be exploited.
The single point of failure it creates can lead to a data breach from one company causing a major ripple of compromises across many other sites. Hackers will use brute force attacks to test stolen usernames and passwords from one source to gain access to another say, bank accounts, Facebook pages, Gmail, you name it. Most recently, the major loss of usernames and passwords from Adobe caused Facebook and Evernote to prompt users to reset passwords to avoid these attacks.
So what should companies downstream from a compromise do to protect users against this fallout? The one approach making headlines is to force all potentially impacted users to reset passwords, which, while effective, is burdensome for users. There are several other steps companies can take on the server side to identify and disrupt these attacks.
Beyond the Reset
For one, identify anomalous activity indicative of a brute force attack and disrupt it. Normally, users fall fairly consistently into a pattern of login activity (e.g., the average user does not generally have more than one active account on any given website). Even if they do, they generally don’t log in to more than one or two accounts on any given day. When you factor in some accidental typos and guessing at forgotten passwords, you can say that any user attempting to log in to more than eight accounts (different usernames) and trying more than a total of 12 passwords is likely performing at least a low-scale brute force attack.
When the credentials of a large website are leaked, the attackers end up with a database of several million usernames and passwords. Attempting to log in to all of those usernames and passwords from a single computer would likely not work due to distributed denial of service (DDoS) protections. So attackers are forced to scale attacks out to many different machines generally within a botnet. This, of course, costs money, time, and other resources, which is why attackers will usually attempt to scale out to the least degree necessary.
Still, time is of the essence. Credentials will rapidly decline in value as time elapses and users change their passwords in response to any breach announcements. Say an attacker has three million credentials to test, 20,000 machines to scale it across, and about three days to do it. This means, each machine would need to test at least two accounts per hour.
Once identified, companies can automatically reject any login attempts from a client who has attempted to login to eight or more accounts from a given connection. They should not, however, provide any feedback about “blocking” a user. By withholding this information, companies can prompt those behind the brute force attack to exhaust the username/password database without any indication or disruption. If attackers realize what’s happening, they could just scale out on more machines to avoid getting blocked.
This way, it’s possible to prevent all but the first four hours of a brute force attack. Of those three million credentials, that means a whopping 2.8 million will remain protected. As a result, the return on investment of the secondary attack—and even the primary attack—is reduced and would potentially become too expensive for an attacker to even bother with in the first place.
Force Password Hygiene and Employ Better Authentication
Just as cross training has proven to prevent injury, so, too, can multi-pronged security approaches. Another approach is requiring better password hygiene by users on sites. This includes requiring that they:
• Rotate passwords after a reasonable amount of time.
• Use a password strength analyzer, and enforce a sane score threshold. That’s it. Don’t apply any other crazy restrictions.
• Never lock an account as a result of failed login attempts or anything an attacker can intentionally trigger.
Companies can also employ some simple steps to make brute force attacks more difficult for attackers:
• Employ CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) on all login attempts if possible to prevent automated brute force attacks.
• Deploy some type of two-factor authentication scheme to make these types of attacks obsolete. While in some instances this approach might be cost-prohibitive, as this and other new identity management schemes gain scale, it will become a more and more viable option for companies to deploy.
• Never tell the users why the login failed, just say it failed. This includes when they get the two-factor authentication orCAPTCHAanswer wrong, but still gets the password correct. This information can aid hackers in working around defenses.
• Increase the information required of a user if their account has experienced too many failures. Of course this is less important if you already require aCAPTCHAor two-factor authentication on all logins.
Related Reading: Hackers Just Made Off with Two Million Passwords, Now What?
Tweet
Michael Callahan is the vice president of global product marketing for the Security Business at Juniper Networks. Prior to Juniper, Callahan was the vice president of product and solution marketing, enterprise security products group at HP. Callahan joined HP through the acquisition of TippingPoint where he served as vice president responsible for corporate, field and product marketing. Prior to joining TippingPoint, he served as vice president and chief marketing officer for CREDANT Technologies. Callahan also spent seven years with McAfee in various marketing roles. He holds a bachelor’s degree in engineering from Ohio State University and a MBA from the University of South Carolina.
Previous Columns by Michael Callahan:Exercising Alternatives to Detect and Prevent Brute Force AttacksExamining The Security Implications of Healthcare.govWhy You Should Connect and Protect in the CloudIn the Smart World, Sharing Is CaringObscurity Is Not Security… Or Is It?
sponsored links
Tags: INDUSTRY INSIGHTS
Application Security
Incident Management
Identity Access
Cloud Security
Data Protection
