Passwords: How “strong” is strong enough, lessons learned from HBGary

11 02 2012

by Benjamin Dupont

In 2004, Bill Gates predicted that “ over time, people are going to rely less and less on passwords” [1]. Yet here we are in 2012 and passwords are still at the heart of security systems. As advocates of privacy, we should continue to embrace the use of passwords in our private lives as they offer a level of anonymity that biometric systems take away. But that’s a topic for a different day. The question I’d like to examine is how strong is strong enough?

What is a strong password?
Ideally, passwords would be extremely long and random. Since we have to remember them (and not write them down), we have to make use of less than optimal passwords. This is trivial information but it raises the issue of what is the required length and randomness of a password?

In [2] and [3], the authors argue that the strength of a password depends on the account; for example your password to access corporate resources or bank account vs the password used to access your kids PBS account [2]. Again, more trivial information.
Another question to consider is how often to change passwords. In [3], Schneier again argues that it depends what the password is protecting. And the value of the asset isn’t the only criteria: whether or not the attacker exposes the compromised account by “ using” the data is a more important criteria. For, example, money disappearing from a bank account is a good indication of a compromised account and changing the password would likely not have stopped the attack [3]. On the other hand, an attacker might use a compromised account to sniff quietly for information on a corporate network. In this case, changing passwords regularly might help. I realize, this is more trivial information, but somewhat less so.
Here’s a final piece of trivial information: don’t use the same passwords across sites, and especially don’t use a corporate password on your private sites.
This trivial information is important in understanding how the security firm HBGary was attacked [4]. Before we discuss the attack, a background on cracking passwords is required.

Compromising an Account: Attacking Passwords
Since passwords are here to stay, it’s important to understand how an attacker breaks passwords. There are two common modes of attacking a password: online and offline.
In an online attack, the attacker attempts to log into an account by guessing different passwords. This attack is circumvented by login delays and account lockout, both prevent guessing a large number of passwords. An attacker attempting an online break-in will likely utilize social engineering or a sniffer rather than randomly guessing passwords.
In an offline attack, the attacker has the password file and the passwords are presumably hashed. If you manage infrastructure that stores passwords, it’s vital that you understand how those passwords are stored. If you’re managing packaged software, it’s likely (hopefully) the vendor is aware of the following issues and has taken appropriate precautions, but if you have in house built systems, make sure stored passwords are adequately hashed.
With access to a password file, the attacker doesn’t have to worry about delays or getting locked out: the attacker can use whatever computing resources are available to aid in breaking the hashes. There are two main approaches to breaking hashes: brute force and rainbow tables.
In a brute force attack, the attacker uses a program to generate passwords. Each password is hashed and compared to the password file for a match. This is where strong passwords come into play: longer passwords with more variation will take longer to crack. Depending on the hash algorithm used, attackers have a more effective tool: rainbow tables.
Rainbow tables provide a time-memory tradeoff [5]. They’re essentially a lookup table for mapping known hashes to passwords. That is, given a hash, a rainbow table will provide the corresponding password in a matter minutes. There are a couple of well known tools that use rainbow tables that will help you recover lost passwords on windows machines, including Ophcrack [6].  By the way, if you’ve never used Ophcrack, I highly recommend you download it and try it on a home computer.
Rainbows tables are easy to defeat. Rainbow tables can’t be all encompassing; they can’t account for every password length with every possible character, and every different type of hash. System designers can defeat hash tables by requiring passwords longer than generated rainbow tables, AND apply salt to the hash. Hashing multiple times is another technique but it’s not as effective as using salt.
Using the salt technique was useful even before the realization of rainbow tables. Each password has it’s own random salt and the salt is stored with the password. With a random salt applied to each password, an attacker must generate a new hash for every account in the password file. Furthermore, the combination of a large enough salt plus password should create a hash that’s not in any available rainbow table. And the table required to hold such a hash would be too large and take too long to generate.

How Did HBGary Fail? Let me count the ways…
We now have enough history to understand the attack on the security firm HBGary. What follows are highlights of [4].
The HBGary website used a little known CMS system which hasn’t been weathered like other popular systems. The attackers exploited a flaw in the CMS which allowed them to obtain a list of hashed passwords. If you followed the first two sections on picking strong passwords and using salt when hashing passwords, you probably have a good idea of what happened next.
The CMS hashed passwords with a known weak hash function, they didn’t salt the hashes, and some of the users had relatively weak passwords. This allowed the attackers to use an existing rainbow table to crack the hashes. But that isn’t where the issues stop.
Normally, when security professionals warn against using the same passwords at home and work, the idea is a compromised personal account shouldn’t lead to a compromised corporate account. The opposite happened at HBGary: compromised corporate accounts provided access to personal e-mail, Twitter, and LinkedIn accounts.  I found this rather amusing.
The article outlines a number of exploits the attackers performed as they made their way through the HBGary network. We’ve heard the adage that systems should be built in layers; a system should not be hard on the outside and soft on the inside. This system appears to be soft inside and out. HBGary is (was?) a security firm that offers services such as secure networking and penetration testing. How could they get these simple points so wrong?

How Long Do Passwords Need to Be?
For your personal accounts, chances are, you only need to worry about online, automated attacks. Choose a password that would be difficult to guess for someone that knows you, and you’ll likely be safe. In other words, don’t use birthday’s, children’s names, pet’s names, etc. In the event that a list of passwords is compromised, hopefully the provider has taken necessary precautions to protect against offline attacks.
What I’m basically stating is that passwords to our personal accounts are relatively safe. There are more important things to protect like financial and personal data. What safeguards are companies like Facebook and Google implementing? I believe encrypting credit card data is standard practice but personal data is likely stored in the clear. That information is likely more valuable to an attacker than the login to my Facebook page.
__________________

[1] CNET News, February 25, 2004, Gates predicts death of password, http://news.cnet.com/Gates-predicts-death-of-the-password/2100-1029_3-5164733.html
[2] Wired, January 12, 2012, Do You Really Need a Password You can Barely Remember?, http://www.wired.com/wiredenterprise/2012/01/simple-pw/
[3] Schneier on Security, November 11, 2010, Changing Passwords, http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
[4] Arstehnica, February 2011, Anonymous speaks: the inside story of the HBGary hack, http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars
[5] freeainbowtables.com, FAQ, http://www.freerainbowtables.com/en/faq/

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: