Password Complexity vs Usabilty

Continuing the topic of security vs usability from my previous post, let's talk specifically about password complexity. Why is a more complex password better than a simple one? It is better because that makes it more difficult for an imposter to crack and thus falsely authenticate as you.

I have been on the Internet since about 1987 and have both watched and participated in the massive growth and usage ever since commercial entities and individuals were allowed on in the early 90's. Almost every business and organization you might deal with today has an online presence involving a web site. And you can usually register an account there which involves creating a password for authentication. In my experience, the password policies vary quite widely from site to site. Some sites still don't seem to care and let you enter short and weak passwords (e.g. 1234). On the other end of the spectrum, some sites require a minimum length, a mix of character types and even provide a strength indicator feedback as you enter it. Some sites are even adding two-factor authentication in the form of a fob/card or more likely an SMS text to your cell phone. Sadly, some sites don't seem to care until they get hacked and have to deal with the PR and legal ramifications of PII being publicly leaked.

One mitigating factor is how valuable you consider your account on a given site to be. If you have not registered any PII or payment information, then perhaps little to no damage can occur and a complex password is not necessarily warranted. But IMHO, that's just bad practice and leads  to a less careful attitude.

As more and more people "got online", the number of bad apples got proportionally larger and they too have grown in skill and continue to develop their password cracking tools and techniques.  Back in the day, it was just simple brute-force exhaustive search of the password space. Then they added dictionaries of common words, rainbow tables, etc. Powerful, parallel computing hardware is now readily available for a low cost to speed up whatever techniques are used. Even worse, when someone's database gets hacked and lots of passwords are captured, that just gets added to the front of the dictionary list to hit the low-hanging fruit first. So we're in an "arms race" with these folks and as long as we're using passwords, the only tactic is to stay ahead of them with length and complexity to make it more costly to crack.

And that brings us back to the security vs usability trade-off. The longer and more complicated your password is, the harder it is to remember and enter it quickly and correctly. A couple years ago, one of my online accounts got hacked (still don't know which one) and some (fortunately out of date) credit card information was acquired. They tried to use it for a purchase and the credit card company flagged the transaction as suspicious due to the outdated address information. This blocked the card and I had to get a new number, etc. I had registered that card on a number of sites for automated, periodic billing, but had neglected to keep a careful list. So I had to rediscover them the hard way as I got notification from everyone of failed payments over the next month's billing cycle.

This episode taught me two important lessons. First, document where you have left your credit card information. Second, use better passwords. I was guilty of using the same simple password on a LOT of sites. My first thought was to change them all to something better, but then I quickly realized that sharing the same one on every site was a serious vulnerability no matter how good it was. And nothing I could remember would ever be a really strong password. So I was caught between security and usability and knew it.

Then an idea formed. What if I introduced a small usability inconvenience that would let me maximize the complexity and strength of all my passwords? I decided to make use of a secure password database program. My original choice was Bruce Schneier's Password Safe. Later, I migrated to KeePass because I wanted cross-platform support for Linux, Windows, Android, iOS, etc. Regardless of the specific application, I only need to create and remember one good password to unlock the database. Then I can store every other password (and associated meta-data) securely. This would let me generate maximum-length, random passwords using all acceptable characters which is the best you can possibly do. Each site gets its own database record and different password from all other sites. So compromise of one site does not give the attacker any advantage on any other site. The usability drawback, however, is that I don't actually know what any of my passwords are. I must have the password database available to copy/paste the passwords into the web browser.

And that leads to a second usability issue. With touch screens like an iPad or an Android phone, you have virtual keyboard and they are not necessarily QWERTY layout. It takes some doing to type in the password database password on such a device because these keyboards typically have different pages for letters, numbers and sometimes special characters are split across two different sections. So entry is not as efficient as a real keyboard for something long and complex.

Even worse is any interface that is presented on a TV screen, like adding a DVR or streaming video player (e.g. Roku) to your WiFi network. The interface is typically a slow cursor (left/right/up/down) to each character using the remote control. I once had a 63-character random string for my WiFi password. After failing to enter it correctly 4 or 5 times in a row, I compromised on the strength vs my sanity trying to use the remote control and changed it to something easier to enter. I would really like to see such devices add a web interface so you could configure them from your computer instead of on the TV screen. Even if that requires an initially wired Ethernet connection.

I also tend to compromise slightly on passwords that must be entered frequently from the touch devices. It really is a pain in the butt to use the password safe on them because of the password entry and then the copy/paste mechanism.

I have been using this system for over 2 years now and it works quite well. At last count, I have 171 records in the database. I've gotten use to the database and it's really not that bad once you become proficient with its use. And I rest easier with regards to the security of my accounts.

That takes care of due diligence on my end, but I have encountered some examples of laxity on the other end. Some sites have no password policy (other than entering "something") or only accept a limited set of special characters (why?). Some have made odd choices or have technical issues. One brokerage site that I use does not allow passwords. They still use a numeric PIN that must be between 6 and 12 digits in length. That is an incredibly small character space. Of course, I use all 12 digits and select them randomly, but still it's only 10^12 permutations. The only mitigating factor is that there is no user name. They use your account number as the ID, so a random hacker with no other information is left to guess two random numbers and see if that happens to equal anyone's account. An example of a technical weakness is Vanguard which a lot of employers use for their 401(k) benefits program. The Vanguard web site password policy is:

Your password must have 6–20 characters, with at least 2 letters and 2 numbers. Don't use spaces.

That's pretty good, but there is another interface to some of your data. I use the Quicken software to manage my personal finances. Vanguard supports downloading transactions and account balances by Quicken. To do this, you give Quicken your web site username and password (which it also stores securely). For the longest time, I could not get the Quicken interface to work. Contact with both Quicken and Vanguard technical support ended with them pointing the finger at each other and shrugging it off. So I did a little experimenting on my own and discovered that the Quicken interface would work if I did not use any special characters in my password. Would have been nice if Quicken could have documented that... but this points out another potential security weakness. If your site supports multiple interfaces, they should all share the same password policy. Otherwise, you have to compromise to the common denominator (i.e. the weakest one).

This post maps to CompTIA SY0-301 exam objective 5.3.