11

I read a long time ago this article about how could work a Password-less Authentication System, which sounded to me like a great idea. I even built it in a small fun little application for fun.

To quote the article, this is how it works:

Here’s how passwordless authentication works in more detail:

  1. Instead of asking users for a password when they try to log in to your app or website, just ask them for their username (or email or mobile phone number).

  2. Create a temporary authorization code on the backend server and store it in your database.

  3. Send the user an email or SMS with a link that contains the code.

  4. The user clicks the link which opens your app or website and sends the authorization code to your server.

  5. On your backend server, verify that the code is valid and exchange it for a long-lived token, which is stored in your database and sent back to be stored on the client device as well.

  6. The user is now logged in, and doesn’t have to repeat this process again until their token expires or they want to authenticate on a new device.

So what do you guys think? Is this really a realistic alternative to password-based authentication?

Edit:

As it has been stated, getting your phone stolen, gives potential access to your emails and SMS, which would compromise this system. But that would also be the case with password-based systems, where you can click the "Forgotten password" link to receive the email to change the password, and could also have installed Google Authenticator. So, in my opinion, having the phone stolen is a weakness for BOTH password and password-less systems.

Maybe the question should have been:

Do password-less authentication add risk scenarios that aren't present in password-based authentication systems?

Community
  • 1
Enrique Moreno Tent
  • 213
  • 2
  • 7
  • 1
    So 2FA without the first factor. This is the "what you have" factor. The problem is the consequence of having that device stolen. – schroeder Apr 18 '15 at 17:13
  • Then use OAUTH instead of your emailing scheme. – schroeder Apr 18 '15 at 17:39
  • Why is OAuth better than this "emailing scheme"? (Deleting old comments) – Enrique Moreno Tent Apr 18 '15 at 17:40
  • Because, as you suggested, you can fully rely on Google's security team to provide security for your login. – schroeder Apr 18 '15 at 17:42
  • But not everyone uses Google's mail service. – Enrique Moreno Tent Apr 18 '15 at 17:42
  • I'm not hopping on this merry-go-round with you. You asked if it was realistic, the answer is a resounding 'no'. Is it possible? Of course, but it is not secure because it includes 0 security, as you yourself mentioned. If you are going to offload the security of your login mechanism to a 3rd party, then use secure 3rd party login mechanisms, which include OAuth. – schroeder Apr 18 '15 at 17:45
  • You say it includes ZERO security, but it requires having access to your email account, which is a form of security. But it is ok, if you do not agree. After all, I was asking for other people's opinion. Thank you for sharing yours. – Enrique Moreno Tent Apr 18 '15 at 17:47

2 Answers2

5

As always, the choice of the authentication scheme mainly depends on what you need to protect and the kind of public you will receive.

As "I forgot my password" link mentioned in the comments is a good example. By the past, for certain non-important websites, I used such links on a systematic basis to open a session:

  1. Click on the "I forgot my password" link
  2. Get the email allowing to reset the password,
  3. If actually required, reset the password to some long random string.

By this way, the security of the access to this site was dependent of the security of my mailbox. I did not have any password to remember, and the password recorded in this site's database was unique.

This procedure seems like dirty-version of the procedure you present in your question.

Regarding security, this works as long as:

  • The authentication source (email, phone, ...) is not compromised,
  • The long-lived token is not compromised.

For a non-important website, when such authentication scheme is correctly implemented, it could be more secured than allowing users to use some silly password already used on a dozen of other websites.

For a website dealing with sensitive data, the user must be in measure to prove his identity. Therefore the usage of a secret password only known by the user seems mandatory in order to proceed with a normal authentication. The usage of email / SMS should remain exceptional as a password reset procedure or as a second factor authentication.

Regarding usability, it would be better to keep such authentication scheme as optional, since some users may prefer to use passwords safes or other kind of password generators to handle their passwords and will not be able to act as they will with your authentication scheme (links provided are just sample of such software).

WhiteWinterWolf
  • 19,142
  • 4
  • 59
  • 107
  • If email is used as an exceptional password reset procedure, one may imagine that it is handled or at least logged differently on the server side so that when you contact the support team claiming "Someone has stolen my access" the fact that the password has been recently changed gives credibility to your request. Regarding long-lived session, most-often there is just no long-lived session. When there are, they are limited to non-critical read-only tasks, any critical task will require the password to open a full fledged short-lived session. – WhiteWinterWolf Apr 18 '15 at 18:01
  • With your proposal, an ill-intentioned person does not need to change the email to enter, he just enters as the legitimate user would do. However, when using a password, the nasty person needs to click on the "I forgot my password" link to get a new password sent by email, which may ring some bells on server side. – WhiteWinterWolf Apr 18 '15 at 18:12
  • Indeed. But if the thief has not changed the email linked to the account, the original user can revoke all tokens (after having secured his email account), which would automatically give him back the access to the web service. No? – Enrique Moreno Tent Apr 18 '15 at 18:14
  • I would be the attacker, I would not change the email associated to your service, I would only change the password associated to the email account. – WhiteWinterWolf Apr 18 '15 at 18:22
  • Yes, but that would be a security problem of the email service, not of the web service. This could happen to the user, regardless of what auth system the web service uses. **But** 2 things are true here: 1) If someone steals your email, he has access to all the web services that use this Authentication system. 2) This password-less auth would not work for email services. (Even though if someone stole my email, losing my twitter account would be the last of my worries :P ) – Enrique Moreno Tent Apr 18 '15 at 18:25
1

One difference between a password-less system and a password system + forgot password is session timeouts. Many systems as a security measure automatically log you out after X minutes. While you could of course do this in a password-less system it would be very annoying to the user. Usability on password-less systems generally depends on long running sessions (i.e. login every few months instead of every day) while sorter sessions are generally not a big deal is password-based systems.

Eric Anderson
  • 111
  • 2
  • They are not a big deal in password-based systems because users tend to use weak passwords that are easy to remember. – Flimm Oct 21 '20 at 08:49