Notes

News, links, research, and product announcements from XOXCO in Austin, TX.

  2. Is it time for password-less login?

    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.

    Further Reading

    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. 

    posted 1 year ago on Jul 25, 2012 | Permalink | 60 notes

  3. Tumblr Notes

    1. sunfox reblogged this from xoxco
    2. neoocean reblogged this from xoxco and added:
      아이디와 패스워드 조합은 빅뱅이 일어나던 시점부터 사용하던 인증 방식으로 서기 2012년에는 너무 많은 문제가 있지만 개발자들은 페이스북 가입자만큼 많은 온갖 이유를 대며 이 방식을 고집합니다. 아이디와 패스워드가...
    3. bjjb reblogged this from xoxco
    4. mbirth reblogged this from xoxco
    5. pwringger reblogged this from xoxco
    6. mosx reblogged this from xoxco and added:
      support passwordless logins...users by sending them...email...
    7. carlsensei reblogged this from xoxco and added:
      currently ‘designed’ puts all...weight of security...its...
    8. experience-ss reblogged this from xoxco and added:
      An interesting post by Ben Brown, on the idea of a password-less login. Be sure to check up his follow-up post
    9. rknla reblogged this from xoxco and added:
      Anyone want to help me hack devise to do this?
    10. chrischelberg reblogged this from xoxco and added:
      An interesting look at how...cutting edge of web development
    11. knorri reblogged this from xoxco and added:
      Interesting idea. What do you think?
    12. marcopompei reblogged this from xoxco and added:
      Muito interessante
    13. over-compensate reblogged this from xoxco and added:
      Ben Brown: Read the follow-up post here. (via Marco Arment)
    14. kvnsmth reblogged this from xoxco and added:
      better way for identifying ourselves...applications than
    15. severalbillionmiles reblogged this from xoxco
    16. johnsheehan reblogged this from xoxco and added:
      like this idea because...stuff very often. If...centralized...
    17. jshmllr reblogged this from xoxco
    18. rober reblogged this from xoxco
    19. milesevenson reblogged this from xoxco
    20. kaspernymand reblogged this from xoxco
    21. codeslinger reblogged this from xoxco

Receive XOXCO's curated broadcast of original essays and links about product design, publishing, and software. Featuring exclusive links to experimental software and limited edition digital downloads.