Password or no password?

I was pointed to an interesting article on Medium this morning, making a suggestion of how to make the login process for systems easier. The premise is that instead of having to remember passwords, the user simply uses the “forgot password” link to set an automatically-generated one every time they want to access the system.

The difficulty with this approach is that it assumes a couple of things.

  1. That the user has an email address. (It’s surprising just how many people who use the internet don’t have an email address.)
  2. That the user can receive his or her emails instantly at any time.

Experience shows that authenticating for a service is a pain in the neck. It’s a web developer’s job to make the process as seamless as possible and the current standard is that, in order to register for a service, one must have an email address. This is difficult, because many users are rarely on the internet and are possibly only registering for your service for a short-term or irregular use.

Within a client project I’ve developed over the past three years, with 50,000 users, around 1% of the users have had difficulties with the registration process. They either have no personal email address, no access to their work emails when they’re outside the office, or the automated emails don’t get through the spam filters.

There’s a laudable trend towards offline apps: apps which require authentication, but which are designed to work primarily without an internet connection. If a password is forgotten in this environment, then there’s no way of recovering a forgotten password without an internet connection.

Encouraging users to set different passwords for every service they use is good, because if someone finds out a single password they use for every service, then they can get into other systems and wreak havoc. However, this may well lead to people using easier (and more crackable) passwords like “password123”. Systems which force users to make better passwords are loathed, despite their good intentions.

“Sorry, but your password must contain an uppercase letter, a number, a haiku, a gang sign, a hieroglyph, and the blood of a virgin.”

There are a number of systems available to help people remember their passwords: from 1Password to Google Authenticator. I’m a fan of Google Authenticator for high-security systems, but using a second app to log in seems to be an extra hurdle for the average internet user.

Another alternative is the one my bank uses: a comparatively easy-to-remember password, combined with a printed list of 100 additional codes, chosen by the system at random, to add to the password.

More and more website-based solutions are making the signup process really easy: only ask for an email address and you’re logged in right away. But: users need to confirm their email address within a certain amount of time to either continue to use the service, or “unlock” the true features of the system.

There’s no great “reveal” here: I don’t have a solution either… yet. When addressing the question of authentication, you need to be sure to consider and answer the following questions. Don’t just assume that the solution everyone uses today is the best one for your website or app, and don’t assume that everyone can verify who they are via email.

  • Do you want to store secure data, or just be able to track who is accessing your content? You might not need to issue passwords, if all you want to do is track your visitors.
  • Does the user data need to be stored securely?
  • Do your users have permanent access to an email-based password recovery system?
  • Do your users have permanent and immediate access to their emails?
  • Is it more likely that a user will have a mobile phone? If so, could you send a temporary access code via SMS instead of email?
Further reading