Your users do not need passwords

Often, one of the first architectural decisions made at the beginning of the development of your site is to use email + password to authorize the user. This bunch is firmly embedded in our heads, and we are already thinking about why we are forcing people to come up with a password. We are used to doing this.

But let's think, maybe your users do not need passwords.

One of the possible solutions is to use OAuth 2.0 , but not all users may have a social network account and a desire to use it on your resource.

But how then to get rid of the password? To this question, I will try to answer in the article.

What's the problem?

The only secure password is one that you cannot remember .

Troy hunt

Password alone is already a problem. It is not profitable, neither to you nor to your users.

For the site owner, the password is not beneficial in that its storage creates an additional vulnerability in the system. No matter how strong your hashing algorithm (and God forbid, do not use it), sooner or later it will become a trifle for new GPUs, and later on the CPU. And if your database leaks into the network, then this will inflict a huge blow on you and your visitors. Without passwords, the base becomes much less dainty prey.

For visitors to your site, a password is an additional difficulty. Inexperienced users will once again use their "regular" password, increasing the risk of losing it. And advanced users will be forced to come up with a special password for your site or use a password manager.

In itself, the phenomenon of password managers is already a crutch that should have shown us all the non-demand and inefficiency of the widespread use of passwords.

In addition, you can further poison the lives of your users by forcing them to periodically change them, or prohibit / force the use of special characters.

How to be?

The answer is not to use passwords. You only need to know the user's email.

When registering on the site, you are somehow tied to user mail. You send letters to her confirming that the user is the owner of the account; you use it to reset your password.

Password reset already sounds like an oxymoron. Indeed, in order to set a new password, you just need to receive an email. All. So why did you make the user think up a password, change it, and use only characters you like?

Indeed, to authorize a user, you just need to send him an e-mail with a generated link, as when confirming your account. This is enough to authorize the user.

Yes, and modern email services are many times more protected and prepared for attacks than a regular website with seals. Entrust password storage and protection to professionals.

Decision

Consider an example of a simple site with PostgreSQL as a database.

Two tables (with a minimum set of fields) will be enough for us:

users :

sign_in_requests :

A few comments about the tables:

• The sign_in_requests table can (and should) be shared with the "Sign Up" table, because in this system their role is identical.
• Based on the point above, in sign_in_requests there are no foreign keys, and the email field is duplicated.
• token does not have to be uuid, you can make shorter tokens, which can even be entered manually. But in this case, the probability of collision and its reliability can significantly deteriorate.
• request_ip - an optional field, used only for rate limit, or for further clarification of the reasons.

The authorization process is quite simple:

1. The user enters his email and makes a request.
2. You generate sign_in_request , and send a link of the form: to the user’s mail https://example.com/signin/callback/email/{{token}}.
3. The user, following this link, makes a request to your database for the presence of such a token.
4. If there is such a token, it is not expired, not used, and it is the last one with such an email (optional protection from Brute Force), then we believe that everything is fine.
5. We expose activated_at=now()to prevent multiple use of the token.
6. Further, everything is the same as in the system with passwords, you can give the user cookie / JWT / etc.

As a protection against spam emails, you can make a rate limit, or not send an email more than once every 10 minutes.

For whom?

Who should use this technique:

• The vast majority of sites on the Internet, including blogs / news sites / forums.
• Corporate sites where your users are already using your internal mail.
• To services that is used periodically, but not often: the website of the Internet provider / payment for services for a month.

And do not use this technique:

• When you yourself are an email service.
• Your main customer is the mobile app / Smart TV / IoT. In this case, it may be worth leaving the optional ability to use a password.

Final words

Although the idea of ​​refusing a password looks wild and unusual, at first glance, in return, it can provide a number of advantages and make life easier for you and your users.

Image Source: https://pixabay.com/en/padlock-grunge-rusty-rusting-76866/