Everyone hates passwords. Here’s how to get rid of them.
There are many ways of user authentication that are simply better than passwords. Some of them work by themselves, others as part of a larger solution. Many of these alternatives are more labor-intensive to implement than passwords, yet more convenient for the user.
There are many ways of user authentication that are simply better than passwords. Some of them work by themselves, others as part of a larger solution. Many of these alternatives are more labor-intensive to implement than passwords, yet more convenient for the user.
In our previous authentication articles, we wrote how authentication plays a role in three business-critical phases but is often neglected, and how the best login is no login at all – you can use cookies without being creepy. Now we dive deeper into the complex world of passwords.
A smooth login is one of the cornerstones of a successful digital service, but many services still trip themselves up before the race has even started. Using passwords is one way to ruin the login experience for the customer.
This article focuses on the alternatives you have.
3 alternatives for P4ssWord5
The alternatives to passwords are many. In this article, I will walk you through the pros and cons of the most common ones. Many of these alternatives don’t enable strong authentication, but we will talk about that in more detail in our next authentication article.
1. One-time password via SMS
Texting a one-time password, or OTP, to the user is a common solution. It’s not very secure, to be honest, but good enough for most innocuous services. A good implementation minimizes two things:
- the trouble of entering the user’s phone number
- the trouble of entering the code from the text message
On Android, it looks like this: you can choose your phone number from a menu listing the numbers found by the application. Unfortunately, it’s not a hundred percent reliable, and you still have to enter your number manually every now and then.
A properly configured server can read the code from the text message and transfer it directly to the application, saving the user the trouble of memorizing the code or flicking back and forth in the message app.
This is the most convenient login experience you can achieve with one-time passwords on Android. It may look complicated, but all you actually have to do is check that your phone number is correct and wait a few moments.
If you can’t configure the server end to read the code automatically for some reason, you can still make the user’s life easier by formatting the text message right. If the message is correctly formatted and the user is using Google Messages as their SMS app, a Copy button for easy copying of the OTP will be added automatically to the notification.
It can still go wrong if your own app’s code field has been custom-designed in a way it doesn’t support pasting codes from the clipboard. This could be the case if the UI has only been specified as images, without proper designer-developer collaboration.
The trouble is that Messages is choosy about how you format the message, and a working syntax apparently hasn’t been documented anywhere.
With iOS, the options are a bit more limited. You can’t ask the system to give the phone number but, if you configure the text field right, the iOS 13 keyboard can offer a single-tap shortcut for phone numbers.
Easy phone number input and retrieving OTPs from messages almost automatically on iOS. Example from Lyft app.
I’m sure there are many applications that do it well on both platforms. My go-to example of a good implementation has traditionally been Lyft.
2. Case Tallink and the smart text field
Tallink used to have an awkward login process. Users had to come up with a separate username, which couldn’t be an email address. On top of that, if you forgot your password, the system always created a new one that you never learned and rarely bothered changing. As a result, “I Forgot My Password” was one of the most visited pages on the site.
When we set out to build a new solution, the product owner gave us a simple briefing:
“Whatever you do, get rid of usernames and passwords”, he said.
“I’m gonna make it happen”, said I.
The result was a smart text field in which you could write anything at all you happen to know about yourself. Telephone number, email address, loyalty card number – it’s all good. The system then does its best to identify you with that information, asks further questions if necessary and finally sends you a login link by email or SMS.
The text field changes according to what you write in it.
This solution will theoretically work with any service that doesn’t require strong authentication.
I have been given leave to present the results: After launch, traffic at “I Forgot My Password” stopped cold.
“I Forgot My Password” visits before and after launch of the new login service.
3. Third-party login services
Facebook login has been a popular alternative for passwords for a decade now. Such third-party login services are usually referred to as “social login”, even if the service is not an actual social network. Also LinkedIn and Twitter provide similar third-party login options.
These services benefit both users and service providers:
User
- Less information to enter
- No need to think up usernames and passwords
- No separate password confirmation required
- Other information is transferred at the same time (e.g. profile picture)
Service provider
- Improved conversion
- Less fake users
- Richer data
The downsides are obvious. Data management is obscure, and users may end up telling more about themselves than they would like. A nagging sense of uncertainty also has a price. Login services are often integrated in a difficult way that requires the user to remember which service they originally registered with when coming back to the service later on.
Google is a natural choice for Android users
Google’s proprietary login service Google Sign-in has been available for quite some time and is a natural choice for Android users. Users are already logged into their Google accounts on their phones in any case, so there is no unnecessary hassle involved. Off the top of my head, I’d also say that Google has a slightly better reputation in the field of data protection than Facebook.
The situation has been less clear cut on the iOS side until recently.
Sign in with Apple
Apple has better cause to be jealous now: it finally launched its own login solution, Sign in with Apple, last year. There are two things you should know about it:
- You have to support it if you want to use another third-party login service (the transition period ended on June 30).
- It lets users use fake email addresses. The service provider can trust the address to work, but there is no way for the user to know which of their addresses was given to the service, so it can’t be used to identify the user in other channels.
Because of the latter point, if you want to support, say, Facebook login in your iOS app, you need to build Sign in with Apple support into all of your other channels as well because you can’t identify users with their email address.
Sign in with Apple gives minimal information to the service provider. It provides the name, possible made-up email address and a unique identifier. It doesn’t transmit the user’s address information like Apple Pay either.
Sign in with Apple enables fingerprint and facial identification. Source: Macstories.
That’s the upside, support for biometric authentication. For some reason, Google has not decided to introduce anything similar for the Google Sign-in service on a large scale, even though it’s pretty handy in other respects.
4. Last but not least: Finnish alternatives for passwords
Our local authentication services merit a chapter unto themselves. The next contender could emerge from telephone operators, who have announced that they are working on the next generation of mobile certificates, or Mobiilivarmenne.
While the previous version lurked inside your phone’s SIM card and thus required a special activation process, the new version will be application-based. It would be a pretty safe bet to assume that it will work like the authentication apps offered by banks.
In addition to strong authentication, available even now, the mobile certificate will also offer a new lower level of security competing directly with the authentication solutions of Facebook, Google ja Apple, as well as Finnish indie solution SisuID.
Even though the mobile certificate lacks iOS-level integration, the operators have a strong market position. It’s thus easy to see success for this alternative in the future, as long as it’s done and priced right.
Whoa, you made it this far! Hopefully this convinced you to give up passwords and choose a better solution for your service’s login. As you noticed, this article focused on services that don’t require strong authentication. In the next one, I will delve deeper into the various options for implementing it, including the use of mobile certificates.
Illustration: Aija Malmioja
