I am an IT security consultant, author, and I love writing about passwords.

My Password is 4.hub.route.edu.

Password security has always been a hot issue but events in the last few years have made it an even more pressing issue to a greater number of people. When I hear receptionists in a doctor’s office sharing strategies for creating secure passwords I know this is now beyond the realm of network administrators and security professionals.

But one thing I have noticed is that many people don’t truly understand why one password can be so much stronger than another so I thought I would walk through the process of cracking a password. In this case, I decided to use as an example the very password that (until I wrote this) I use for the admin account on this blog.

So like I said in the title, my password is 4.hub.route.edu.

That isn’t the best password I have come up with but it is still fairly strong. It is 15 characters long, contains a number, letters, and some periods. It took me just a couple logins to actually memorize that password. The word components are fast to type because we are trained to type in whole words. And there are four parts, each one ending with a period. The repetition of the period helps the memory process.

Chances are that no one would be able to go to my admin page (which itself is protected by a different password) and just guess that, no matter how much they knew about me and no matter how many of my other passwords they knew because I have never used that password anywhere else. As of writing this article, I can do a Google search for “4.hub.route.edu” and there will be no results.

But the real risk isn’t someone being able to keep trying to guess my password via the admin page, the real risk is someone finding a new 0-day exploit that allows them to dump the users table in my database and get the hash of my password (which happens to be $P$9YCJ/QwbFcgbo7OtfWGYYE8sVJBxtF/). If someone can get your hash, they can now try millions of password combinations without you ever knowing it.

Cracking a password hash is a lot like trying keys in a lock. A hash is a string of characters derived from your password that is calculated in such a way that it is nearly impossible to work backwards to discover the original password so it is relatively safe to store. When you log in to a system, it will run the password you enter through this same complex formula and the result should be the same.

So when I first created my password on this blog I entered 4.hub.route.edu. WordPress ran it through these formulas and came up with the hash $P$9YCJ/QwbFcgbo7OtfWGYYE8sVJBxtF/ which it saved it in the database. The next time I log in, I enter my 4.hub.route.edu password, WordPress runs the same formula on that password and it comes up with $P$9YCJ/QwbFcgbo7OtfWGYYE8sVJBxtF/ which matches the hash it has stored so it knows that I am using the correct password even though WordPress never stored my actual password. Now what is special about these formulas is that it is extremely rare that any two passwords will create the exact same hash (a concept known as collision).

So if someone is able to obtain my hash, they can’t directly get my password from that, but they can try millions or even billions of different passwords and run each one through the formula until they find one that produces that exact same hash. It is a lot like having a lock, you can’t easily create a key from it but you can try a bunch of keys until you find the one that works.

Now when it comes to passwords there are actually hundreds of trillions of possible passwords someone might choose. Even with a cluster of powerful computers it could take decades to try every possible password. Fortunately for hackers, most people aren’t that clever with their passwords. There are a number of strategies they use that can drastically reduce the number of passwords you need to test to crack a password. Below is that strategy

1. Hash Lookup

First, an attacker will check to see if someone else has cracked the password before, using either a local database or an online database such as onlinehashcrack.com or hash-database.net or one of the hundreds of other similar sites. In the past few years there have been many large sites that have been hacked and their passwords leaked. If you password was ever one of these, chances are it will appear in one of these databases. Likewise, if you select a common password that others may also be using, it also might be on this list.

In the case of WordPress, the hashes are created using PHPASS but for the sake of this example, let’s just assume they use MD5 hashes like many other systems use. The MD5 hash for my password 4.hub.route.edu is 7914881ba9b78fa307db6ef0db675e29. You can search any online databases for my hash and you will not find it listed anywhere (at least at the time of writing). If your password is one that you have never used before and others likely have not used, you should be safe (try googling one of your passwords, you may be surprised how many results you get).

If your password hash does not appear in one of these databases, there are also rainbow tables which are massive databases of precomputed hashes consisting of every possible password up to 8-10 characters in length, depending on the algorithm. If your password is less than eight characters long, your password surely will be cracked at this stage. However, you will not find 7914881ba9b78fa307db6ef0db675e29 in any of those databases so I am safe so far.

The lesson here is to never use a password less than ten characters long. Never use the same password on multiple systems. Don’t try to be clever with your password, that never works (NCC-1701 is a very common password).

2. The Word List

Since most passwords consist of dictionary words or something similar, checking every word in a dictionary or a specialized wordlist http://svn.isdpodcast.com/wordlists/ is a quick way to find a weak password. Most hackers will use lists of the most common passwords such as this because chances are very high that someone will be using one of those passwords. It normally doesn’t take more than a minute to go through even a gigantic list of words.

In my case, even a Google search for my password turns up nothing so even if you had the massive list of words that Google has indexed you still wouldn’t be able to crack my password.

Considering this, you can see why so many systems simply probihit any password that is a dictionary word.

3. Rules and Patterns

If a dictionary or wordlist check fails, the next step is to try some of the common (albeit innefective) tricks people use to make a password more complex. If you asked me what I thought was the most common password pattern I would say a proper noun (such as a name) followed by 2-3 numbers. So it would be smart for a hacker to take each word in a wordlist and add ever possible number from 1 through 999. If that doesn’t work, you could try reversing each word or doing simple substitutions like using the number 3 instead of the letter e. It really does not take much effort for a cracking program to try hundreds of different patterns.

For example, a dictionary word may be “password” so a rules-based attack my try PASSWORD, dRowssap, P@SSW0RD, p@ssW0rd, dr0Wss@p, passwordpassword, @ssW0rdp, dp@ssW0r, p@9sW0rd, 1p@ssW0rd, p@$$W0rd, ppp@ssW0rd, 1p@ssW0rd, and thousands of other variants of the word. Depending on the number of rules and the size of the wordlist, this step may take only five to ten minutes and will crack a great number of passwords.

If an attacker has sufficient processing power, another effective strategy is to try two dictionary words together with various delimiters between them (such as dashes or periods). If you had a wordlist of 100,000 words and tried every combination of two words that means you would have ten billion possible combinations. Trying different delimiters between the words would make it a little bit harder but not much.

You probably wouldn’t want to try three-word combinations because that would take you up to a quadillion (1,000,000,000,000,000) possible combinations which would not be an effective strategy. In the case of my password there is a number and three other words that would likely appear in a dictionary but testing for four-word combinations would mean there are 100 quintillion (100,000,000,000,000,000,000) possible passwords, so the odds are my password would still be pretty safe.

The lesson here is that a strong password is not a matter of being clever, it is a matter of beating the numbers. Passwords should always contain three or more words or other sequences.

4. Brute Force

If a password hash doesn’t show up in a database or hasn’t been cracked before, does not show up in a list of common passwords or dictionary words (even after trying hundreds of common variants), the only method left is to simply brute-force the password. This means trying every possible combination of letters until you find the password. It would be like trying to crack a simple bicycle lock, you would start with 000 and try 001, 002, 003, and so on until you got to 999.

In the case of passwords you would need to try every combination of lowercase letters, uppercase letters, numbers, and punctuation symbols. In other words, imagine a bicycle lock where each dial contains abcdefghijklmnopqrstuvwxyz ABCEDFGHIJKLMNOPQRSTUVWXYZ0123456789`~!@#$%^&*()_-+={[}]|\:;"'.?/ and there are eight or more dials. This is why so many systems require that you use a variety of characters because using different types of characters is like making each dial larger. And making your password longer is like adding more dials.

 

 

Now brute-force attacks are much smarter nowadays using techniques such as mask-based attacks. These types of attacks basically use knowledge about passwords to make the brute-force process much smarter. For example, if you look at this chart http://xato.net/img/UpperCaseLettersLarge.jpg you will see that uppercase letters are very likely to show up in position 1 but are extremely rare after position 8. Knowing this, it would be more effective to not even bother looking for uppercase letters after the first few characters. Now if you look at the distribution of all character sets in this graph http://xato.net/img/CharacterDistributionByPositionLarge.jpg you can see that much can be done to optimize the brute-force process. Nevertheless, these rules become less and less effective the longer and more complex your password gets.

The big secret here is if you can force a hacker to have to use a brute-force attack and you have a password that is at least 15 characters long, chances are that you have won. Eventually computing power will catch up so that even 15 characters might be enough but the good thing is that these numbers grow exponentially so a 16-character password is almost 100 times stronger than a 15-character password and a 17-character is more than 9,000 times stronger!

So What Makes a Password Strong?

Your password must be something very unique and one that you have never used before. In fact it should be so unique that if you did a Google search for it, there would never be any results. You can’t just take a word and dress it up a bit, you need 3-4 words or other sequences to make a password strong. And finally it has to be long. It helps to throw in some numbers and pumctuation but most importantly it has to be long.

10,000 Top Passwords

Back when I wrote Perfect Passwords, I generated a list of the top 500 worst (aka most common) passwords which seems to have propagated quite a bit across the internet, including being mentioned on GizomodoBoing Boing, SymantecLaughing Squid and many other sites. Since then I have collected a large number of new passwords bringing my current list to about 6,000,000 unique username/password combos, including many of those that have been recently made public*. Read More…

The Worst Password Tips

 

Because I have always been so fascinated with passwords, I always like to hear different tips people have for creating strong passwords. However, I have to admit that most of the tips I run across are actually kind of lame and really are not very secure. Unfortunately, some of these tips are quite popular and get passed around way too much. In fact, I rarely see any advice besides these I have listed. Read More…

Worst Password Policy Ever?

I have seen many silly and overly complex password policies over the years, but I think that the TSA’s TWIC password policy has to be the worst I have ever seen. Their password policy is as follows:

  1. Minimum password length is eight characters.
  2. Passwords must contain at least one of each of the following: one alphabetic uppercase, one alphabetic lowercase, one numeric, and one special character.
  3. Passwords shall not contain any two identical consecutive characters (example: 22apples, 14588904).
  4. Passwords may contain no more than two identical consecutive characters in any position from the previous password.
  5. Passwords shall not contain any dictionary word.
  6. Passwords shall not contain any proper noun or the name of any person, pet, child, or fictional character.
  7. Passwords shall not contain any employee serial number, Social Security number, birth date, phone number, or any information that could be readily guessed about the creator of the password.
  8. Passwords shall not contain any simple pattern of letters or numbers, such as “qwerty” or “xyz123″.
  9. Passwords shall not be any word, noun, or name spelled backwards or appended with a single digit or with a two-digit “year” string, such as 98xyz123.
  10. Pass phrases, if used in addition to or instead of passwords, should follow these same guidelines.
  11. Passwords shall not be the same as the User ID.
  12. Password length will be selected to provide a level of protection commensurate to the value or sensitivity of the resources or data it protects, but not less than eight characters.

Complex password policies are frustrating and confusing to users and can even lead to habits that subvert the security of the system they are trying to protect with the passwords. But this policy just takes it to a whole new level.

All I can really do is address it one point at a time:

1. Minimum password length is eight characters.

My first thought here is that if you are going to have such an extreme password policy, you could at least set the minimum password length to ten or even twelve characters. The password length is crucial to password security and eight characters just isn’t long enough anymore. Besides, having a longer minimum length requirement alone would eliminate the need for most of those other policies.

2. Passwords must contain at least one of each of the following: one alphabetic uppercase, one alphabetic lowercase, one numeric, and one special character.

Usually I complain about password policies that require all four types of character sets, but in the context of all the other rules below, this one doesn’t seem so bad anymore.

3. Passwords shall not contain any two identical consecutive characters (example: 22apples, 14588904).

I see no justification for how this rule makes someone’s password more secure. Consecutive characters certainly do not make a password more guessable or more crackable and this policy seriously makes me wonder if the writer’s of this policy even understand password security at all. In fact, you could even argue that in the case of a brute force attack that two consecutive characters would take longer than other character combinations. For example, if you are trying to crack the password 14588904 via a brute force attack that starts at 00000000 and ends at 99999999, incrementing by one character each time, then when it gets to 14580000 it still has a ways to go before it gets to the actual password. In this particular case, the password 14581234 would be cracked first even thought it doesn’t have consecutive characters. Overall, the average time for any set of passwords would not be affected at all by this policy and it really seems like a policy created just for the sake of having a policy.

4. Passwords may contain no more than two identical consecutive characters in any position from the previous password.

I’m not even completely sure what this means, but I am guessing that if your previous password was 8qTaYbg$aMVVruEg and you wanted to set your new password to &2Ta3xfWNG=Arn9e, it would be rejected as not being secure enough because it has two of the same characters in the same places as the last password. Now I don’t know if any of their admins have ever tried cracking someone’s password, but you definitely don’t start with the previous password (if you even know that) and start matching character by position.

5. Passwords shall not contain any dictionary word.
6. Passwords shall not contain any proper noun or the name of any person, pet, child, or fictional character.
7. Passwords shall not contain any employee serial number, Social Security number, birth date, phone number, or any information that could be readily guessed about the creator of the password.
8. Passwords shall not contain any simple pattern of letters or numbers, such as “qwerty” or “xyz123″.

These policies started with a good intention and took it one step too far. Apparently their logic is that if your password is something that would show up on a password cracker’s wordlist it is bad, therefore if if your password even contains a dictionary word, then it must also be bad. So if I chose a password like $$Superman&#xyz123, which is a very strong password, it would be rejected by the system as not being secure. Again, I’m not really sure these people understand password security.

9. Passwords shall not be any word, noun, or name spelled backwards or appended with a single digit or with a two-digit “year” string, such as 98xyz123.

This one I somewhat agree with. It is still a little extreme but probably fair. Still, this could be eliminated with a minimum 12-character policy.

10. Pass phrases, if used in addition to or instead of passwords, should follow these same guidelines.

Why did this even need to be said on an already cluttered and confusing list? I think that anyone would assume that the requirements of a pass phrase would be the same as those for a password. I’m starting to think that whoever wrote this was actually trying to make this list long hoping it would make them look smart or something.

11. Passwords shall not be the same as the User ID.

This is the only policy that actually needed to be there, and is something most users have come to expect in a policy. However, this is yet another policy that could likely be elmiminated by having a minimum length requirement.

12. Password length will be selected to provide a level of protection commensurate to the value or sensitivity of the resources or data it protects, but not less than eight characters.

Again, something that totally goes without saying and kind of sounds like something taken from a higher-level policy document. The list of policies is already intimidating enough to users that you really don’t need to be stating the obvious. Besides, if you have to say something like this, why not just make all passwords a minimum of 12 characters or more.

 

My Password Policy

So what would I use as the ultimate password policy? If I was ever in the position to set an organization’s policy, and it required a much higher than normal security, it would be this:

  1. Minimum password length is 15 characters but can contain anything you want including spaces.
  2. Your new password shouldn’t look too much like your last one.
  3. Don’t reuse this same password anywhere else.

Then, I would provide a short list of example passwords to spark their creativity such as this:

  • www.craving-tacos.mx
  • whitefish44.JPG
  • C:\program files\green
  • 1-800-orange piano

I know that many administrators would have a very hard time with my policy and some people will ask what if a user sets their password as a string of 15 a’s? After all, this goes against what most administrators are taught in school. My answer to that is that the password aaaaaaaaaaaaaaa has not appeared on any wordlist I have ever seen, so far is not in any rainbow tables, would be a strange thing for someone to guess, and would take forever to crack via a brute force attack so I say it’s actually a pretty good password.

 

 

 

 

 

 

 

How I Collect Passwords

Some of you out there know that I have been collecting passwords for quite some time. Since 1998 to be exact. Originally I did it just to have big wordlists for password cracking, then I started gathering them for research on my Perfect Passwords book, finally it became like a big ball of string where you just do it because it makes no sense to stop now. My list currently contains about 6 million unique username/password combinations (not counting those from public lists from Gawker, RockYou, and others).

So I thought that some people might be interested in how I collect these passwords. Note that all of these passwords have already been made public and can easily be found by anyone. There are no passwords on my list that have not already been made public. Also note that so far I have never shared this list with anyone.

  1. I use tools such as Athena, which does massive Google searches for and collects passwords in the format “http://user:password@example.com/members”. This tool can easily gather 200,000 combos in a day but the majority of these are already in my database. I run this about once a month.
  2. I have a script that nightly leeches from a huge list of well-known password sharing web sites.
  3. I use a number of Google alerts that watch for common keylogger log formats. This is just one of many that I use. There are a surprisingly huge number of these logs that can be found via Google, although it is sometimes difficult to parse the passwords from the content.
  4. I use Google alerts to watch for SQL database dumps of forum and other common software databases.
  5. I also use Google alerts to look for passwords on pastebin.com and other related sites.
  6. I use a script that grabs all the Google alerts as RSS feeds and parses out URLs, then another script visits each site and leeches the passwords.
  7. I use RSS feeds from filestube.com to watch for and download password lists that might show up on a number of file sharing sites.
  8. I use RSS feeds from various torrent searches that I put into uTorrent to download automatically.
  9. I use a number of IRC bots that hang out in a large number of IRC channels where password sharing happens. These aren’t as effective as they once were but I still use them occasionally.
  10. I use a script to automatically download posts from various Usenet newsgroups, although most of those are just spam nowadays.
  11. I visit a number of public and private hacking-related forums to get wordlists and hacked passwords. I often pay for VIP memberships (usually the lifetime ones) so that I can access premium content areas. Leeching from forums has to be done manually, because you often have to comment on posts to be able to download the lists, but occasionally I will spend half a day leeching from these forums. Some forums will let you subscribe to posts and will include the entire post contents in the email. This bypasses the often-used “hide hack” and I can just use another script to save that inbox to local files.
  12. I use various FTP search engines to watch for interesting filenames that might show up on FTP sites.
  13. In the past I have used various P2P networks (such as LimeWire) to search for files but those don’t produce many results nowadays.
  14. Every once in a while someone will send me a big dump of their own lists they have collected.

As these scripts collect data, it is all dumped into a directory on my hard drive and regularly I run program I wrote that parses all the data looking for password is common formats.

Here are some examples of what the program recognizes:

http://www.example.com/members/ L:user1 P:password1
http://www.example.com/members login:user1 password:password1
http://www.example.com/members user: user1 pass:  password1
Login: user1 passw:password1
L:user1 P:password1
username:user1 password:password1
http://www.example.com/members L: user1 P:  password1
username = user1  password= password1
u=user1 p=password1
username    user1  password    password1
login id: user1 password: password1

It grabs the username/password combos and saves them into text log file. After a while these files accumulate and I merge them into my master database. In the database I perform cleanup steps such as removing passwords from well-known password hackers (such as pr0test) and other junk that might appear. I also strip domain names off usernames that are email addresses.

What is interesting about all this is how difficult it is to find new username/passwords combos that aren’t already on my list. These scripts can easily collecting 100,000 unique username/password combos every day, but only a few thousand of those are not already on my list.

After 12+ years of collecting passwords, I have found a few interesting facts:

  • Although my list contains about 6 million username/password combos, the list only contains about 1,300,000 unique passwords.
  • Of those, approximately 300,000 of those passwords are used by more than one person; about 1,000,000 only appear once (and a good portion of those are obviously generated by a computer).
  • The list of the top 20 passwords rarely changes and 1 out of every 50 people uses one of these passwords.

There are a few flaws with my list that I should point out:

  • Many of these passwords have been cracked from hashes so a good percentage of them would by nature be crackable, skewing the statistics some.
  • These passwords are largely dominated by passwords from adult web sites, which are the ones mostly publicly shared. This results in a higher percentage of adult-related and obscene passwords.
  • These passwords are usually from web sites that often do not enforce strong passwords policies that a private organization might. This is bad because this data doesn’t truly reflect all passwords, but on the other hand it shows the kind of passwords users will select if a password policy is not enforced.
  • My scripts only grab usernames and passwords between 3 and 30 characters long, all others are thrown out.
  • None of the passwords contain a colon, because that is the delimiter used to separate usernames and passwords in the combo lists my scripts generate.

So that is how I collect my passwords, maybe someday I will share the list itself.

Incidentally, the one tool I really wish I had time to build is either a proxy server or a Greasemonkey script that will automatically parse and log usernames and password combos from web pages that you visit. That would be extremely helpful!

 

 

 

 

 

 

Another Strange Password Policy

It still amazes me that after all the education over the years that there are still so many poor password policies out there. Anyone who has ever filled out a web form likely has run into these overly complex and frustrating passwords policies.

But sometimes a password policy is an indication of a bigger problem. For example, today I was setting up an account and entered a very strong password and was presented with the following error message:

Apparently what caused the error is that I used a period in my password and this policy only allows for numbers and letters. But the bigger question here is why doesn’t the policy allow for numbers? Why does the password have to start with a letter? And why is there a limit of 20 characters?

The reasons why these concern me is that they sound more like technical limitations rather than being motivated by strict password security. Normally when you store a password, you first create a hash of the passsword and then store the hash. The nice thing about hashes is that being hexidecimal values you don’t have to worry about the security risks of special metacharacters and symbols. You also don’t care about maximum length because the hash is always a fixed length, whether your password is 10 characters or 100 characters.

However, if you are worrying about non-alphanumeric characters and the password length, that suspiciously sounds like they are storing the password itself, not a hash of the password. Being a healthcare orginazation this is a big deal. And although we like to think that most big companies have security teams that prevent things like this, the recent announcement that Sony stored passwords in plaintext tells us otherwise.

Secret Questions
A little lower on the page I ran across another problem, they are letting the users select the secret question as shown here:

The problem with this is that most users are not qualified to come up with quality secret questions. At best you will see questions asking for their favorite color (how many colors are there really?), their dog’s name (just look on their Facebook profile), or where do they live. To make matters worse, a shockingly high number of people will actually put the answer as the question itself, as a hint. If you disagree with me on this and have a site that lets users set their own secret questions, check your database and you will be surprised how bad they can be and how often they reveal the answer in the question itself. This is one of those little secrets that hackers have known for years.

Finally, the worst offense is the way in which this site lets you recover your password:

If you click on the Forgot Password link, you are shown the above form which lets you set a new password if you know the secret question. The problem with this is that this makes the secret question as powerful as the password itself, because just knowing the answer lets you set a new password. Normally, answering a secret question will initiate a process whereby the registered email account receives a message that a password reset was initiated and that they need to click a link to finish the process.

The reason we do this is because secret questions are not secure. The information in a secret question is something that is easily discoverable, has a limited number of possible answers, and is a fact that will never change. We can only partially compensate for these problems by sending an e-mail notification to the user and requiring a click through.

In this particular case, the user sets their own secret question which has a high chance of being insecure and then all that is needed to set a new password is to be able to guess that answer, no email access required.

The sad thing is this company has already appeared in this database once before, I hope it doesn’t happen again, especially not with my medical information.

Ars Technica Says Don’t Punish the Users

I was reading this ars technica article that talks about how some are angered by LulzSec releasing a sample of their Sony passwords. They quoted one Twitter user who basically told them to not punish the users for Sony’s sake.
But here’s the problem with that argument: those one million accounts accounts have already been hacked, and at least a few people already have that information. Making the list public forces Sony and the users to take this seriously. If the list is not made public it is too easy to get lazy about it.
Hiding the passwords really doesn’t protect those users one bit whereas making this stuff public will bring a lot of attention to the matter.

How to Guess an Admin’s Password Without Them Knowing You Are Trying

This should be pretty obvious, but a lot of people don’t seem to be aware of this old trick. Normally, if you try to guess another user’s password and it fails, the attempt will show up in the event viewer of the domain controller. However, there is a way you can try to guess an account’s password without the attempts ever being logged.

It’s actually pretty simple: just unplug your network cable. Read More…

Why my password’s better than Y0ur P@$$word

http://www.nurs.co.uk/news/specials/cms/1171535504212694732419_1.htm

New Passwords Feed

I was playing around with the cool new Yahoo! Pipes site and built myself a feed on password topics. I’m sure I will be tweaking it some as I learn how to use pipes, but I thought I’d pass my pipe around to others who are interested in passwords. You can view my password topics pipe here:

http://pipes.yahoo.com/pipes/iLQCZHG42xG0wG8iXqIxGw

You can also subscribe to the feed using RSS, JSON, e-mail or phone.