Vox Pop

Development — Software, Personal, or Otherwise

This website is being deprecated. All archives and new writing is being moved over to MatthewReinbold.com.

Death to the Password

Questioning the Basics for Something Radically Better

Ye Shall Not Pass!

Over the course of the past month I've come across a number of people writing about the security (or lack thereof) of the password. The timing is a surprise. Computer scientists have been coding username/password validation routines for almost as long as there has been software to limit access to. Even Matthew Broderick, in the early benchmark for questionable computer action in film, War Games, was well versed in what a password was used for thirty years ago (even if back then they called it a "codeword").

Despite their ubiquity passwords have failed for decades. As design demigod Luke W points out login screens are wrought with usability and security issues. Some facts that he tosses out:

  • The average person has between 7 and 25 accounts that they log into every day.
  • People report authenticating about 15 times in a typical work day on average.
  • 70% of people do not use a unique password for each Web site.
  • Password recovery is the number one request to help desks for intranets that don't have single sign-on portal capabilities.
  • The top 5 passwords at Gawker (based on released records) accounted for roughly 1 in 4 passwords. The top password, 123456, came in at over 3,000 uses within the dataset of 188,279.
  • A survey of 34,000 MySpace passwords revealed that the most common were "password1", "abc123", "myspace1", and "password".

This Login has More Components than my Online Banking Does

We should use super-strong, randomly generated passwords without repetition. But we'd never remember those given the dozens of sites we have to log into every day. So, much to a hacker's delight, we pick something easy and use it everywhere.

The problem is compounded when we're on a mobile device. Typing anything on tiny mobile controls is painful. Depending on the complexity of the authentication method, there may also be additional hoops to jump through (look to the right and tell me that doesn't just bum Tim Berners-Lee right out). And I certainly don't want to be spending time doing tech support for password recovery issues when I could be making new stuff.

Maybe its time to let the mobile device be the replacement for some shared secret. That's an idea floated in a great piece by Harry Fuecks (harryf) on github. Why use a mobile phone?

Because you and your phone are one thing; a single organism. You get extremely nervous when you're parted from it. It is your precious; once you get past the lock screen, you are intimately connected to it. And 83% of young people go to bed with their phone. Some older ones too. This is not a shared device or even that thing you leave lying around on your desk unattended. If you happen to catch someone fiddling around with it, you're liable to get testy. So all additional layers of login, beyond the lock screen, are at best superfluous and at worst, a reason to delete apps.

And logins are dead because typing a username and password on mobile is both a horrible and unsafe experience. Horrible because smartphones are not good devices for accurate typing and unsafe because people use their phone in public spaces like a bus where someone may be looking over your shoulder.

So what does granting access look like in this highfalutin, password-free world? Activate the device. Again, from the piece by harryf:

We send you a link by SMS or E-Mail containing a link comprised of an activation code. Tapping on the link results in our app being launched in "activation mode". The app then "phones home" passing back the activation code and some unique identifier for the device. That's it.

About the same time I started playing with authentication methods done in this way Ben Brown at XOXCO issued a similar sentiment. Here the means of identity is your email address rather than a mobile device. From the article:

Each time a user needs to login, they enter their email address and receive a login link via email.

… this design would allow existing users to login with only a few clicks and no typing - select an account from a list, click a link, and they're done. For users who do not already have an account, the process is the same - they will type only their email address, and receive a link via email. This email logs them in and validates the email in one fell swoop.

This is exceedingly clever. As Ben points out most services already send email to new accounts to "verify" they're valid. Password reset notifications are sent to an email on file. The email is already the proof of identity. These traditional systems already assume the user has a private, protected email inbox. The password is really just window dressing.

Best part? Your system never has to worry about a password hack; there are no passwords to steal. There are other services out there - Twitter, Facebook, Google, Stackoverflow, etc. Seemingly any halfway competent technology is providing some flavor of authentication (Oauth, OpenID) that "ease" the login burden. But hitching your horse to one of these means you now have a vendor dependency. Twitter goes down? You're down. Don't tell me it doesn't happen.

I've been incorporating these concepts into TradeGrade and the results are very exciting. By combining these approaches I'm able to provide a better user experience, easier mobile engagement, and an overall more secure system while coding less. If that's not exciting to you as a developer you're in the wrong profession.

After launch I'll write up the nitty gritty where we'll go from theory to practice. Speaking of which - are you interested in fantasy football and looking for a league? Shoot me a comment and let's see about getting you hooked up.