No more username/passwords: Just use a 3rd party for authentication.

It’s 2016, your site/app should not require a password. Use a third party to authenticate your users and make the web a simpler, safer, better place.

It’s 2016; your app should most likely not require a username nor a password. You really should use a third party (email, phone, social) to authenticate your user, and skip the antiquated habit of forcing/allowing users to choose a username & password.

3rd-Party Schemes for Login / Sign-Up

  1. Email: Send the user a link to enter the app.
  2. Phone: Send the user an SMS with a link or code; clicking the link or entering the code on the app lets them enter.
  3. Social Media: Let the user identify themselves via FB, Google, Github, or some other provider.

In each of these schemes, the sign-up flow is the same as a log-in flow and the user does not need to know/choose anything new for your site. Simple and good.

Barring special circumstances, making a user choose their own username / password just does not make any sense in 2016. Every user has an email, a phone number, and/or a social media account. Usually all 3. Choose the one that makes the most sense for your app and use that one for authentication.

A Simpler World For Users

No more thinking. No discussions on ‘correcthorsebatterystaple’ and LastPass and tiers of password sensitivity. No more remembering username and password for dozens of sites.

No more password leaks. No more hackings. No more iCloud leaks. Users shouldn’t need to go through repetitive ordeals of finding, entering, and managing usernames and passwords that match criteria.

Sign-up and log-in are now the same flow for the user; from their perspective they can just use your app without worrying about whether they’ve signed up for it in the past or which of their 3 passwords they should use or what unique username they can come up with.

A users now can’t forget their username and password, because they don’t have a username or password. (And users should be kept logged forever to begin with; see below.)

A Simpler World For Developers

Relying on 3rd-party authentication is also much simpler for developers. No more ‘email is taken’, ‘username is taken’, ‘email is malformed’, etc. Nothing. If you can receive an email at the address you gave me, that’s good enough for me.

No need to deal with the cumulative knowledge about password security. Understanding Rainbow tables and Bcrypt and hashes and salts. It’s hard and error-prone and the error surface should be kept minimal.

3rd-party flows are harder to mess up: if you make the entry token/code time-sensitive (expires within a few minutes) there’s almost nothing that can go wrong (although I’d love to be corrected on that): That’s an impressive attribute of a authentication scheme.

Furthermore, if an app has a username/password scheme, it must support a ‘forgot my password’ flow (usually via email/phone) which means the app supports a 3rd-party authentication flow already. By relying on it as the app’s main entry flow, it is easy to see the app ends up with a simpler subset of its existing logic (e.g. only one way to enter instead of several).

A More Secure World

3rd-party verification makes brute-forcing impossible, because login can only occur in the window after requesting an entry link/code, or via social media. Easily-guessed passwords do not exist because passwords do not exist. Security and happiness go up.

The app maintainers have less security worries because they’ve delegated the authentication to someone else ( Email / Phone / Social media provider). These providers are usually powerful players (e.g. Gmail / Phone companies / FB ) with powerful security abilities — both preventing as well as detecting a compromised user and restoring their control. Obviously users trust and value their email / phone / FB account enough to ensure that as a practical matter they will always be in control of them.

A user does not need to trust you with their password, or variant of-which.

Stay Logged In Forever

As a side note, it is worth advocating that most apps should let the user stay signed-in for as long as possible. Modern browsers remember the username/password anyway, so auto-logging out is pointless.

If a site can afford it security-wise, it should just leave the users logged in permanently to begin with (better UX for a returning user). If it can’t afford it, you definitely don’t want a username/password that can be cached a browser/OS, and you should again use 3rd-party verification.

A result of this means a user would need to use the 3rd-party verification (whose main downside is obviously the heavier friction) very rarely — essentially only when logging-out or when accessing on a different device. For the vast majority of cases, this can be as little as once ever per user for the app, or at the very least once ever per user per device for the app.

Which 3rd-party verification should my app use?

This is an issue to be addressed elsewhere, but the considerations are quite straightforward. Social media is usually best from the app’s side, as you can get significant info about the user as well as provide the smoothest flow. If your users are expected to have privacy concerns, an email solution may be more appealing to your users. If you will be used primarily on mobile devices, perhaps a phone number. One can choose a combination of methods, thus granting more flexibility to users, at the cost of a slightly more complicated setup.

TLDR: No more username/passwords: Just use a 3rd party for authentication.

I can prove I am me because I control my email, my phone, and my FB. That’s more than enough proof for anyone. In 2016, that is me.I shouldn’t have to think about any other authentication details, nor trust anyone else.

We should all stop requiring or allowing users to choose and manage a username and password. Let a user use their email, phone, or social media to authenticate, and make the web a safer, simpler, better place.

If you enjoyed this, please give me a ❤ to help spread the word. :)

--

--