XOXCO

  1. Jul 29, 2012

    More on password-less login

    by benbrown

    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!