The short story is, hackers were able to gain access to his accounts, not by guessing or brute forcing his password, but by calling into the customer service lines of Amazon and Apple, where employees of these companies happily handed over access to his accounts in return for a few tidbits of easily collected information. After gaining access to one account, the hacker was able to quickly gain access to several others, including Mat’s Gmail, Twitter, Amazon and Apple profiles, using password reset tools. As a result, Mat has concluded that our current assumptions about web security are woefully out of step with the intertwined nature of cloud-based services:
"The disconnect exposes flaws in data management policies endemic to the entire technology industry, and points to a looming nightmare as we enter the era of cloud computing and connected devices.
"Password-based security mechanisms — which can be cracked, reset, and socially engineered — no longer suffice in the era of cloud computing."
So, what impact does this have on my password-less login idea that relies on the same mechanism as the password reset tools that ruined Mat’s week?
Since Hacker News and @lukew tweeted links to my password-less login post this morning, almost 400 people have tweeted about it and sent in their feedback. There is a nearly 100 message thread on Hacker News discussing the various strengths and weaknesses of my suggestion. Opinions are too varied to attempt a summary, but there’s a lot of good thinking going on in this thread. Here are a few follow-up thoughts and responses to some of the comments I’ve received.
Are texts or IMs better? My big brained studio-mate Patrick suggested that a text message might work better in some cases than an e-mail. Someone else suggested sending an instant message. There are definitely benefits to using texts or IMs, such as the fact that these get pushed to the user in a more direct way than email does. However, sending email is very easy for developers to do, and sending text messages and IMs requires interfacing with potentially complex third party APIs.
The reason I originally suggested email as the conduit for these links is that it is there is no need to rely on third party APIs or tools - virtually any development platform can send email with little or no configuration.
Is it possible to do this via text, IM, push alerts, or heck, by sending private messages on Twitter? Sure! I would encourage developers working in these areas to give it a try. But email is simple to implement, and is already being used for 2 out of the 3 login processes we all do every day: email verification and password reset.
But seriously, why not Oauth? A few people told me that I was being too harsh on Oauth, and that logging in via Twitter was already easy enough. And then Twitter went down or three hours, and nobody was able to login to anything. Meanwhile, the leader of the Oauth 2.0 specification process quit because he feels that Oauth is headed in the wrong direction. Don’t get me wrong, I think Oauth is very handy and works fine for a lot of places, but because of developer complexity, shifting specs (how many times do you want to re-implement a multi-step handshake?) and changing end user preferences, I think email makes a very nice and safe alternative.
How about use my browser, my phone, or a USB dongle to identify me instead? For exactly the same reasons as above. As a gadget nerd, I think that being able to login to my account using a a hyper-secure NFC handshake with my phone would be super cool. But for purposes of developer ease, user familiarity and because its available today as in right now, I think email still wins. But ok, yes, Mozilla Personas looks kind of neat, OK?
"But email is not actually instantaneous!" said several people. True, but it is most of the time.
"But what if I want to login from a friends house and can’t access my email?" said a few other people. I think this is a pretty small edge case, but if you are really concerned with this scenario, I’d suggest providing a password-based backup. Hacker News user “woah” suggested a brilliant compromise: simply reverse the order of the password reset tool and the password field on the form. Users who don’t want to use passwords can get a link sent via email, and users who do (or can’t access email for some reason) can login in the traditional way.
Regarding my suggestion to autocomplete usernames - @srslyjosh reminds us that exposing email addresses is a bad idea for a variety of reasons, including spam, phishing and others. You should never reveal a user’s email address! My suggestion is to allow users to type either their username or password, but to show only a user’s “real name” or non-email username in the drop down menu.
Finally, I saw an implementation of a similar login system already in practice at LaunchRock.com. To create an account and get started, all you need to do is enter an email address. Once you do, you’re logged in and ready to go. You’re only required to set a password - via a password reset tool - if you somehow get logged out. Nice!
Logging in to web sites is ironically one of the most difficult tasks put before our users. Usernames and passwords are hard to remember, and harder than ever to type on the tiny on-screen keyboards of mobile devices. Even large, successful websites report that they receive an outsized number of support requests pertaining to login problems. We need something better.
As multi-device software developers, we’re interested in making these login processes as simple as possible. If you want to access our products on multiple devices, why should you be required to login with a username and password on each device? What a pain!
My personal solution to the too-many-password problem is to use completely random, automatically generated password when I create an account. Most websites will allow me to stay logged in forever, and on the odd occasion that I need to log in again, a password reset tool will send a link to your email account that will allow me to login again. This way, I don’t really have a password, but I can always gain access to any account, as long as I still have access to my secure email account.
Here’s what login form looks like now:
Facebook login has 6 different controls you must interact with before logging in.
Yahoo has 9 controls on their login form!
Since a user may or may not already have an account, we have to offer the option to join as a separate choice. Existing users must remember both their username and password. In many cases, an invalid combination won’t be revealed until after the form has been submitted, forcing the user to re-enter both the username and password. And if they still can’t remember, it’s off to the password recovery tool.
In the best case scenario, our expert user is able to login with one attempt. But in many cases, the user will be required to type these values multiple times, and may ultimately be sent off to their email client anyway. When creating an account, the new user will almost certainly be sent to check their email in order to validate their email address.
At An Event Apart, @lukew talked about a login design pattern where the username field would autocomplete, allowing a user to quickly select their name from a list instead of typing the whole thing. Then, once a user has successfully logged in once, the site can at least remember the username forever, offering it next time as a choice.
(An argument could be made that it is bad practice to tell random strangers what is and isn’t a valid username, since this makes it easier to target only valid usernames during break-in hacks. However, considering that most services these days already expose a directory of users via profile pages and friend finders, this is in my estimation not a significant risk.)
This is a step in the right direction, as it only requires the user to remember a password. The application can also adjust accordingly if a matching username cannot be found, pivoting from login to account creation.
But we’re still requiring users to remember an eight-character string of nonsense — or more likely, we’re encouraging our users to “secure” their account using a password like “password” or “123456.” (See http://www.lukew.com/ff/entry.asp?1590)
No More Secrets
I think an even better solution would be to remove the password completely, allowing users to login with only an email address. Each time a user needs to login, they enter their email address and receive a login link via email.
Combined with @lukew’s suggestion of pre-populating the username field, 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.
In addition to making it easier to login, this authentication system could be built to allow the login link to be used on multiple devices. Imagine if your new users only had to enter an email address one time to login to your software on their laptop, phone, tablet and any other device they might have. The login link could be extended to work with native app URL-handlers, so that the login link could automatically launch a native app and pass in authentication details at the same time. With web apps, it couldn’t be easier - with one click, the user logs in and launches into your experience, continuing exactly where they left off.
But what about…
Keep in mind, most services already send new users out to their email clients to validate their email address before gaining full access. And we know that a shockingly high percentage of returning users will need to use the password recovery tool to login. In a best case implementation of this pattern, where cookie expirations are set for the distant future and your users do not frequently reset their browsers, it would be possible for a user to login to your service on multiple devices and stay logged in forever, having typed their email address only one time.
There are existing systems that allow users to login without usernames and passwords, oauth being the most popular. Oauth enables users to login using an existing account from another service, like Twitter or Facebook. But logging in with oauth carries with it all sorts of unknown and potentially undesirable consequences, like granting access to friends lists and social networking profiles. It also hands over the keys for your service to a third party, putting your app and users at the whim of external downtime and API changes. And while oauth seeks to simplify login, it is likely that your users will be sent to the third party service, be required to login with a username and password, and then be asked to review and approve complex and frequently misleading permissions for your app before being sent back to complete the login. Is that really easier?
As a developer, there is a another incentive for not collecting passwords: you no longer have to worry about storing passwords in your database. This doesn’t excuse you from running a secure service, but it reduces the number of things you need to protect. Wouldn’t it be nice to know beyond the shadow of a doubt that you will never be responsible for a massive password leak?
To keep things secure, the login link sent via email should have a limited life span: usable only once, or for a short period of time. These links may be stored in a browser’s history, or in a proxy or caching system. And we must keep in mind that this whole process assumes that the user’s email account is and will remain secure - this is the same assumption that most password reset tools already make. With these considerations in mind, I wouldn’t recommend going password-less for anything too sensitive.
I am currently planning on implementing passwordless login for SendTab, which will hopefully make it drastically easier for users to get up and running on multiple devices. What about your apps? Can you see a world without passwords? Tweet your thoughts at @XOXCO.
I posted a follow-up to this essay after nearly 400 tweets about it. Read it!
Read @lukew’s post about login difficulties, which links to this Arstechnica discussion of how passwords never worked.