How strong are my current passwords?

WARNING: This is the geeky post.

The strength of a password is determined by three factors:

  1. The length of the password,
  2. The complexity of the password, and
  3. The processing power available to the cracker.

The formula looks like this:

  • Strength = Complexity ^ Length / Encryption Operations per Second

Where:

  • Strength = the amount of time it would take (in seconds) to process all permutations of a password,
  • Complexity = the number of different characters in the character set that the password was drawn from (e.g. numbers only = 10, lower case letters = 26, lower case + numbers = 36, etc.),
  • Length = the number of characters in the password, and
  • Encryption Operations per Second = the number of permutations a cracker can try per second.

Given that a modern desktop computer can perform over 1,000,000 encryption operations per second*, we can calculate how long it would take to run through all of the permutations of passwords of varying length and complexity as follows:

image

This chart shows the exponential trend of each of the average complexity curves mapped on a logarithmic scale.

Er, what?

English translation:

  • Exponential = Imagine a chart that looks like the right hand side of the letter U
  • Trend = With so few data points, the chart looks rather jerky. So, I told Excel to display a trend line, instead. It smoothes the curve.
  • Average Complexity Curve = The average amount of time it would take crack a password of a specific length and complexity.
  • Logarithmic Scale = Vertical axis goes up by powers of 100 rather than linearly (1, 2, 3, etc.)

So, how strong are your current passwords? Are they strong enough? Stay tuned…

* I got this number (> 1,000,000 encryption operations per second, or crypts/second, or c/s for short) from an interview with the creator of a password cracking tool called John the Ripper. Here’s the interview. It’s worth a read, if you’re at all interested in this stuff. I found the number in a question on the second page, second paragraph.

How are passwords cracked?

The simple answer to that question is that passwords are cracked by guessing.

Now, I know what you’re thinking – that the corporate login system will lock someone out after five failed attempts. Sure. But, by the time a cracker comes to the front door of your system, they’ve already guessed your password.

How?

Well, it likely started with a successful SQL injection attack that gave the cracker access to a database containing user account information. Sure, the passwords were encrypted. But, now that they have the cipher text, they can start trying to crack it.

Dictionary Attacks

The first thing they’ll do is to try all of the passwords on lists of commonly used passwords and default passwords. This is called a dictionary attack. It will likely crack several passwords in the database, since these are, after all, common passwords.

Foiling a dictionary attack is quite easy. Just don’t use common passwords. Take a few minutes to follow the links above to see just how easy this is for crackers.

Brute Force Attacks

To crack even more passwords, the cracker can instruct their computer to try every possible password until one matches. This is called a brute force attack. This type of attack is guaranteed to work – eventually.

The key to thwarting brute a force attack is to use strong passwords. Password strength is affected by two things:

  • The length and complexity of the actual password, and
  • The processing power available to the cracker.

Obviously, you cannot control the second. But, you can control the first. I’ll cover password strength in more detail in the next post. But, suffice to say that the longer and more complex your password, the stronger it is.

Email Attacks

Finally, there’s one more way a cracker can “guess” a password: They can change it.

How?

Assuming the user account information database that they downloaded also includes email addresses (which many sites use as the logon id), the cracker now has two pieces of information about you: Your email address and a password that you use on at least one website.

Using the knowledge that many people reuse passwords on many different sites, including email, the cracker will naturally go to your email site and try to login using your email address and the cracked password. If it works, then not only can they read your email, they can also potentially change your password on other sites and intercept the new, system-generated passwords.

Sure, some websites (notably banks) now require you run a gauntlet of personal questions before allowing you to change your password. But, others do not – including Facebook which is rapidly becoming defacto authentication standard across the web.

There’s only one way to prevent this kind of attack – don’t reuse passwords across sites – especially email!

Now that I’ve scared the pants off you, stay tuned for a deeper (geekier) discussion of password strength, and some (less geeky) recommendations regarding passwords.

How strong are your passwords?

I stumbled on a good (very geeky) article about password strength last week. (I’ve since lost the link, or I’d add it here.) It turns out that my passwords aren’t as strong as I thought. So, I’ll be addressing that over the coming weeks by creating unique passwords for every web site, device and system that I log onto with long, complex passwords. Why go to all that trouble? I plan to explain this in a series of posts beginning today, including:

  • How are passwords cracked?
  • How strong are my current passwords?
  • How strong should my passwords be?
  • How can I handle password overload?

On Source Control and Flow

While working on a new WCF front-end for some legacy software today, I wanted to go look at how another team setup the WIX file for their service. So, I fired up a second copy of Visual Studio and began fighting with AccuBridge. Here’s the sequence of events:

  • Launch Visual Studio
  • Open solution from Start Page
  • Wait...
  • Wait some more...
  • Wait a little while longer...
  • Accept changes that AccuBridge found in the repository
  • Wait...
  • Realize I opened the wrong solution
  • Try to open correct solution
  • No response, just a throbbing AccuRev icon in my status bar

image

  • Wait some more...
  • Try to close Visual Studio

image

  • Wait a little while longer...
  • Finally, AccuBridge finishes futzing around and allows me to open the correct solution
  • Wait...
  • Wait some more...
  • Wait a little while longer...
  • Accept changes that AccuBridge found in the repository
  • Open the WXS file and find the line of code I need

Without AccuBridge, this process would have taken 2 minutes, tops – even with accidentally opening the wrong solution. With AccuBridge, this process took a rather frustrating 10 minutes. I almost forgot what it was I was looking for.

Some might argue that I should have just popped over to Windows Explorer and viewed the file in Notepad. Others might argue that I should turn off AccuRev integration in Visual Studio. But, neither of those solutions is optimal: one loses syntax highlighting, the other loses source control integration.

It seems to me that the proper solution would be for my source control provider to wait for an explicit command before running off to check the repository for updates. It also seems to me that a plug-in should allow the parent application to close, regardless of what it is trying to do when the end user asks to close the application.

Why these things don’t work this way, I do not know. One thing I do know – it would do wonders for my flow.

iPhone Developers Conference

As I mentioned in the previous post, I will be attending an iPhone Developers Conference in late April.

Here are the sessions I plan to attend:

Friday, 4/23:

Saturday, 4/24:

Sunday, 4/25:

Disappointingly, not all of the sessions have an abstract. However, the remainder of the sessions seem to focus on game development and things like “in app purchasing,” which seem much less relevant to our environment. So, I’m pretty sure I’m in the right sessions.

I’ll likely be tweeting while I’m at the event – like I did from the Agile Open Northwest conference last month. (That turned out to be a great way to remember what I learned.) And, when I get back I’ll likely be blogging, so watch this space!