Classic authentication processes with a username and a password are great except for two things: the username and the password. Here is my rant about how we can do better.
Usernames suck
Users often forget their username. Mostly because it all started like this: “Fabien is already taken, please choose something like fabien_027”. Why should I care? Of course, there are other Fabiens on your platform. However, I want your customer service to call me Fabien, and I want my name to be Fabien in my account panel. And not Fabien___huet with 3 underscores because I was annoyed by your system.
Plus, next time I come, I won’t remember the “_027” or the triple underscore, so you will have to send me an email to help me retrieve that username.
You know what is 100% unique, and that I will not forget? My email! Please, let me sign with my email.
So, ditch the username.
Passwords suck
I don’t want to manage passwords. I don’t want to remember them. I don’t want to lose them. I don’t want to forget them.
Plus, most websites get it wrong. They ask for stupid human complexity with bad mathematical entropy passwords. “P4p4y4$*“ can be cracked in 9 hours. “This_password_is_super_safe” takes 16 nonillion years to crack (16 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 years, yep, that much). You can check that on https://howsecureismypassword.net/. Instead of secure password that you can easily remember, most password rules ask you for a weird and unsafe password that you will quickly forget.
Of course, a good password manager is an excellent solution to that problem. However, today, how many internet users have one?
So, ditch the password.
A better solution: the email
Yep, just that, the email. This is the solution I choose when I build something today.
When the user lands on the login page, he has only one field: the email field. And only one button: “Send me my login link”.
- The user enters his email and clicks the button.
- The server sends an email with a link like https://myapp.com/login?tokenLogin=new_login_token.
- The client clicks on the link.
And voilà, the user is logged. The navigator saves the token in the cookies, and the user can start using your application.
Way easier to manage server-side
Think about it. No password security management! No password reinitialization! Fewer forms, less logic!
The user exists? Send him a new token valid for 15 minutes. The user does not exist? Create the user and send him his token.
The only thing you have is an expiration date for your token.
Minimal customer support
That system is pretty much foolproof.
As safe as possible
If someone hacks into my email, he has access to all my online accounts. So I use a hard TFA (two factors authentication) for that one.
Of course, if you are a bank or an email company, keep the password, ditch the username and force your users to use a TFA. And not this ridiculous fake random keypad with 6 digits, please.
But if you are not and that you are not willing to set up a TFA system, please rely on your user’s email security system.
Bonus point: it solves the email verification
Checking that the email exists is an issue. You don’t want to bother your users too much. However, you want to make sure you have the right data. Now it’s simple. The user logged once? The email is valid and verified. Never logged? Clean every week.
Malus point: your users may not like it
When the first laptops without a cd player shipped, many people went crazy. Then they realized they had not opened their player in ages.
It will be the same for passwords. Hang on tight!