TL;DR

User authentication and authorization have to make a tradeoff between high security and high usability. In this week’s reading club, we discuss passwordless login triggered by this excellent post, Passwordless Login Done Right, that presents passwordless login solution unloq.io.

Username And Password

This is the traditional way, a user in sign up form enters its username password, and repeats the password in the password confirmation field. After successful signup, the user is automatically logged in the application. Password strength was not crucial in the early days.

Fighting The Bots

Developers figured out that it is possible effortless to automate the signup process. So a new sign up step was introduced. Username field becomes an email to which the activation application link is sent after successful signup. Users must have access to the email inbox to activate the account by clicking the activation link. After that, log in with username/password was possible. Developers moved bot fight to email service developers because they should come up with smart ways to bot fight during the email service signup process.

Password Strength

Password strength becomes essential because the automated login was easy to implement. Password strength downgraded application usability. At first, a strong password meant hard to remember a password. So we started writing passwords down on paper, or like Joey from Friends, you could write your PIN at your favorite ATM machine.

Then hackers cracked database access of LinkedIn (and other popular services) and revealed a well-known fact that we all use the same password for all our online accounts. Another authentication usability downgrade, different password for every service that we use. Hard to remember password requirements become hard to crack passwords. Password LittleAstronautOnAnUnicronTail is hard to crack the password, but relatively easy to remember.

Password Managers

To overcome password strength and many password usability issues, password managers were born. There you protect with one hard to crack password an infinitive number of hard to crack passwords. Auto-Login is done with little help from Javascript magic.

2 Factor Authentication

Let’s make things more complicated but secure. The second device was introduced, your phone. After a username/password, you receive another secret on your phone that should be entered into the application. You enter the horror story after you lost your phone.

No Password With Login Link

The second device is your email. You enter in login form your email, and application send’s to it email with a login link. Link click automatically logs you into the application, and that is valid for some time. Risk is when your email account is hacked or if the email with a login link is intercepted by hackers. Email is not encrypted communication.

Risk mitigation is to use Gmail as your email service, and that login link is valid for a short time (less than a minute).

The increase in usability is significant.

Reset Password

Here you use reset password feature every time you need to log in. You will receive your reset password link in your inbox. After link click, you get reset password form where you set up your new password. Use that new password to log in and forget about it.

We have the same risks as with Login Link.

No Password With Phone

You enter your phone number as a username, and you will receive a one-time-password as SMS. Use it to log in.

Risk is stolen phone, and mitigation is to have six digits phone PIN code.

Conclusion

Remember that high-security authentication for your application is not essential if you have zero users.