Your users don’t need a password

One of the first architectural decisions taken at the beginning of your web site development is often the use of email + password to authorize the user. This pair has stuck in our heads, and we don’t think why we make people to create a password. We are used to doing this.

However, let’s think, perhaps your users do not need passwords.

One possible solution is the OAuth 2.0, but not all of your users have an account in the social network and want to use it on your site.

And how do you get rid of the password? On this issue, I’ll try to answer in the article.

What’s the problem?

The only secure password is the one you can’t remember
Troy Hunt

The password is already a problem. It is not good for you or your users.

For the site owner, the password is an additional vulnerability in the system. No matter how strong your hash algorithm (God forbid don’t to use them), sooner or later it will become a nonsense for the new GPU, and later for the CPU. And if your database will leak into the network, it will deal a huge blow to you and your visitors.

For your visitors, the password is an additional challenge. Inexperienced users will use their “regular” password, increasing the risk of losing it. Advanced users will have to come up with a special password for your site or need to use a password manager.

The phenomenon of password managers is already a dirty hack, which should show us all the inability and inefficiency of the passwords.

In addition, you can make life of your users miserable by forcing them to periodically change password, or require using a special characters.

What should I do?

The answer is — don’t use passwords. You only need to know user’s email.

When users register on your site, you are already dependent on their email address. You send mail with confirmation links; you use it to reset user’s password.

“Reset password” is already sounds like an oxymoron. Because you can change your password just by following the link from email. There you go. So, why did you force the user to create a password, change it and force use of your favorite special characters?

For authorize users, you just need to send them a email with the generated link, as with email confirmation. This is enough to authorize the user.

Modern email services are many times more protected and prepared for hacker’s attacks than a regular website with funny cats. Entrust the save and protection of the password to professionals.

The solution

For an example, let’s look at a simple site with PostgreSQL as a database.

Let’s make two tables with a minimum set of columns:

users:

sign_in_requests:

Some comments about them:

  • sign_in_requests table can (and should) be a same with the “Sign Up” table, because in this system, their role is equivalent.
  • Based on the point above, we don’t use foreign keys in sign_in_requests table, since we duplicated email column.
  • token doesn’t have to be a uuid. You can make it shorter, for manual input. But in this case, the probability of collision and security can will get worse.
  • request_ip is an optional column. Use it only for rate limiters, or for similar reasons.

The algorithm:

  1. The user enters their email and makes a request.
  2. You generate sign_in_request, and send a link with token to the user’s email, like that: https://example.com/signin/callback/email/{{token}}.
  3. The user, follow the link from email, makes a request to your database for the token.
  4. If such a token exists; (AND) it isn’t expired; (AND) not used; (AND) it is the last with such email (optional Brute Force protection), then we guess that everything is OK.
  5. Set activated_at=now() to prevent multiple use of the token.
  6. Finally, all the same as in the system with passwords. You can give a cookie / JWT / etc to user.

For the spam protection by email, you can make a rate limit, or don’t send a mail more than once every 10 minutes.

For whom?

Who need to use this technique:

  • Most of the internet web sites, like a: blogs / news sites / forums.
  • Corporate sites where your users are already using your internal email server.
  • Services that use periodically, but not often: billing systems / site of the Internet service provider.

But don’t use this technique:

  • When you are an email service (like Gmail).
  • Your primary client is a mobile application / Smart TV / IoT. In this case, using a password can be easier.

Result

Although, the idea of giving up the password looks crazy and unusual, at first glance, it can give a number of benefits, and make life easier for you and your users.