blog

iPhone wanting a password.Photo by Yura Fresh on Unsplash

The Password Must Die

by | Feb 12, 2013 | Developer Blog | 0 comments

Passwords are everywhere. We have too many of them. We know we shouldn’t re-use them, but we already have too many and we can’t remember another one. So we use one in multiple places and we get in trouble when one website is compromised. They cost us time and money when we have to reset them. Despite the pain, cost and weak security they bring us, we’re only getting more of them.

Their ubiquity is a function of their nature. Passwords are usually input using the same interface used for other functions (e.g., your keyboard.) Authentication by other factors require specific inputs to a system. “Wait,” you say. “What are other ‘factors’?” Excellent question.

Authentication Factors

Authentication takes three general forms, called factors. You are authenticated by

  • something you know (a password or the answer to a set of security questions),
  • something you are (biometric identifiers, such as your fingerprints),
  • something you have (a security certificate, security token or smartphone),
  • or a set of these in the case of multi-factor authentication.

So, instead of providing a password, you could be using your fingerprint or a special security token. This sounds great, except that these other factors cost more to implement. Biometric identifiers require special hardware (which comes with concerns about tampering, driver installation, and hygiene.) Security tokens either require special hardware (e.g., smartcards, USB tokens) or have the added bulk of a screen so you can read the current one-time-password. So, who wants to pay for the extra hardware? Anyone who wants serious security.

You see, these other authentication factors are already used by people and organizations which require better security. It’s called multi-factor authentication because you usually have to provide a password and a security token or a password and a biometric identifier.

Problems With Passwords

“So what—that doesn’t help me have fewer passwords.” You’re right. In fact, passwords are not going away. Instead, you’ll be seeing passwords used along with other factors as multi-factor authentication becomes more common. But there are solutions to the problem of too many passwords.

You might also be inclined to think that a few longer passwords should do the trick. You would be right, provided the target system accepts long passwords. And your long passwords have the correct number of numbers and letters of the proper case. And the correct number of punctuation marks. And don’t contain prohibited words.

You see, developers go insane when they build password-protected system. They start thinking of (ineffective) ways to make the system harder to compromise. Unfortunately, their creative rules make the system harder to use and annoy users into less-secure methods of storing the specially-crafted password. (Have you ever found a sticky note on a monitor or under a keyboard?)

For the developers in the crowd, here are the password rules that work:

  1. Passwords must be of some minimum length, and
  2. passwords must not be an exact match for a word in the system word list.

Beyond this lies madness and a lot of disdain from your account holders. Please note that I would suggest several other methods for securing the system that do not involve imposing rules on the user’s password. These include things like throttling log-in attempts, expiring passwords, and requiring the user to change his password after some background process brute-forces it.

Security Questions Are Worse Than Passwords

Let me take a moment to talk about security questions. Yes, this is a tangent, but you need to know how to handle these things.

Back in the day, your bank would ask you questions to verify your identity. The traditional query was about your mother’s maiden name. (Aside: my mother never changed her name, so I learned quickly that the question was of limited value.) The problem with security questions is that they need to be memorable, unchanging, have only one answer and not be part of a public record. (Don’t get me started on questions that may not make sense for many people.) This makes creating good security questions very difficult. Then there is the other problem that everyone is asking for the answers to the same security questions. How many different companies know where you met your spouse? (How do you answer if you aren’t married?)

Here’s a simple guideline for answering security questions:

  1. If the organization allows, write your own questions. This allows you to ensure that you aren’t going to share the same information with more than one company.
  2. Make sure that your answers don’t make sense. (Example: Q: Which fruit brings back happy memories of your childhood? A: Mountain Laurel smells like grape Kool-Aid®.)
  3. Record and store your questions and answers in a safe place.

Let’s talk about that last requirement, “a safe place.”

Password Vaults

A password vault is a tool that stores private data, usually passwords, but also security questions and other valuable information, in an encrypted data store. Most often, this means picking one strong passphrase to protect all the others. This is a bit of hassle (as are most security measures) but it also offers some additional comfort—the knowledge that a compromise of one account does not cascade to other accounts. There is a side-benefit: so long as you have access to the vault, you never need to know any password but the vault password. (This is actually quite wonderful if you share accounts with someone else.)

Countless applications offer such secure storage of private data. KeePass, 1Password, LastPass, (Keychain for OS X users,) and Dashlane are just a few of the many applications that will do this for you. I only have experience with LastPass and Keychain and can say that I will not willingly go back to memorizing passwords. So please, pick one of these. Use it. Trust it (which is scary at first.) Your life will be better because of it.

Single-Sign-On

So, on that topic of having fewer passwords, there is a way forward. The world has lots of options when it comes to authentication. You probably have accounts with some of them. Here are a few of the more well-known identity providers:

You don’t need me to tell you that Google has more experience storing your credentials safely than your neighborhood blueberry farm. We’ve already established that more passwords are generally inconvenient. So when want to log-in to a site or application, use the single-sign-on option.

Multi-factor Authentication on the Cheap

Suppose you’ve decided that this is good advice and you’re using a password vault and single-sign-on. How can you improve your information security further? You can use multi-factor authentication where it is available. Here are a few places you might see it:

All of these authentication systems allow you to use SMS with your mobile phone as a second factor for authentication. (Sadly, neither Mozilla Persona nor Sign in with Twitter offer multi-factor authentication as I write this. To be fair, it’s not clear that it makes sense for Mozilla Persona. Twitter may have something in the works.)

Things you can do

As a user, you should

  • use a password vault and encourage others to use password vaults,
  • use strong passwords, secure in the knowledge that your password vault knows them,
  • make up answers to security questions—for heaven’s sake don’t answer them honestly—and,
  • use single-sign-on and multi-factor authentication where they are available.

If you don’t write code, you can stop here. Kudos to you for reading this far.

As a developer, you must only implement password-based authentication schemes where necessary. To prevent adding one more password to each user’s life, you should:

  • learn and implement single-sign-on for your web sites,
  • learn and implement single-sign-on for your apps, and
  • learn and implement single-sign-on for your sanity.

When single-sign-on is not possible, please refrain from imposing silly password rules and implement multi-factor authentication. Then, at the earliest opportunity, implement single-sign-on.

+ more

Accurate Timing

Accurate Timing

In many tasks we need to do something at given intervals of time. The most obvious ways may not give you the best results. Time? Meh. The most basic tasks that don't have what you might call CPU-scale time requirements can be handled with the usual language and...

read more