One of the hard decisions I had to make early on with Shopi was how I was going to manage logging in. It’s a problem any app developer with a back end service is going to have: how do my customers prove who they are?

The traditional choose-a-username-and-password dance is rapidly becoming untenable. People have so many online accounts that it’s just not reasonable to ask them to remember yet another combination just for you, especially if you’re just a tiny part of their lives like Shopi is for most users. If you do ask them to do it, my bet is that one of following outcomes will cover 95% of use cases. Your customer will:

• Eventually forget their password, and get angry at you. Or abandon the app.
• Re-use a password they use everywhere else. Now you have to guard a trove of keys into other people’s lives.
• Not bother signing up in the first place.

None of these are good.

There’s also the issue of abuse: what’s to stop some random lulz-seeking wit from writing a script to create 20,000 accounts?

The Social Network

Many apps are now offering the option to log in via Facebook, Google, Twitter, etc. While this can be easier initially — especially when the user is already logged in and can just click an ‘authorise this app’ button — it outsources your customer’s identity, a core part of your business, to a third party.

And while it’s possible that people still retain some vestige of faith in these companies’ promises to protect their privacy, that doesn’t carry across to your app, which, for all your customer knows, might go ahead and post special, not-to-be-missed offers on their time line.

The people at Mailchimp wrote an article citing several additional downsides of social logins from when they ran the experiment.1

Passwordless Login

The idea is simple: rather than asking for a username and password from your customers, you ask for an email address and send them random, single-use, time-limited password instead. (Even better, send a link with the password embedded.) When the user logs in, the server then sends back a permanent, super-secure, randomly-generated password which is stored for future logins.

The thinking goes: you need to handle the case where the user has forgotten their password in any case, and this is usually handled by emailing a password reset link. Why not extend that to cover all logins?

I first heard about the idea of passwordless login in a post by Ben Brown (although I expect it’s an older idea than that). Marco Arment later expressed his support for the idea, reiterating it on the ATP podcast. Since then several other people have written about it.2

Here are a few pro’s and con’s of the approach in no particular order:

• BAD: There’s a password in the user’s inbox. But it’s only valid for a limited time, usually just a few minutes until it’s used for initial login.

• BAD: You have to store the user’s password in cleartext on the server. (Otherwise you couldn’t send it to them) But the reason you’re supposed to hash your passwords is that people tend to reuse them across services: if you get hacked you don’t want to make the situation worse by exposing your customers to further hackage.3 But the passwords we’re talking about are randomly generated by your server and are of no value anywhere else.

• BAD: People need to access their email to log in. This is moderated by the fact that, for an iPhone app at least, they’re very likely to have it already set up for email. We can also make the password relatively short and memorable so that they can easily type it in manually if the login link doesn’t work from their mail client.

• BAD: It’s a bit weird. I have yet to come across another app or web site that does it this way.4

• POSSIBLY GOOD: One of the problems identified by Mailchimp is that users who logged in via a social account often forget which social account when they later need to sign in again. Most people probably have less email addresses to choose from, often only one. Also, the email address they used to log in can be found by searching for the login email later. (Well maybe, if they’re not one of the many people who inexplicably delete email as soon as they’ve read it).

Putting My Money Where My Mouth Is

So, admittedly with some trepidation, I decided on a passwordless login system for Shopi. The decision was strongly influenced by it being an iPhone app, which meant that (a) I assumed a high probability of the user having email access on the device, and (b) I could use a custom URI scheme to encode a login link that would flip back to the app and login with a single tap.

So how’d it work out? So far, really well. I’ve seen very few people take the ‘use offline’ route, almost no abandoned attempts at creating accounts, and had zero feedback complaining that it’s weird or confusing.

The only real problem was of my own making. Lots of people (probably around 25%) were entering a password they made up — and of course getting knocked back repeatedly — rather than waiting for the email. Why?

Looking again at the signup process, I realised I had put “Enter Password” as the place-holder text in the password field and made it focused, popping up the keyboard — I was practically yelling at the user to ENTER A PASSWORD, NOW! Not my best design work.

So I changed the password field place-holder to “Password From Email” and left it un-focused. And I haven’t seen a single frustrated customer repeatedly trying to login using “margie123” since.

Conclusion

Passwordless login can work well for an iPhone app, and it has a number of clear advantages over the traditional route. I also think the same lesson would apply for any smartphone platform.

1. Although the real take-away from that article is that small improvements to the login UI can have a big impact, which is, ironically, something that I found out the hard way as well (described later in this post). ↩︎

2. Including “Passwords Are Obsolete”, and “Logging In Through Your Inbox” ↩︎

3. You may also not want to entrust your employees with access to such potentially sensitive information. ↩︎

4. As I was writing this entry, I came across another app that’s just started doing this. ↩︎