0

I implemented a passwordless authentication with a good UX in mind. But I am not a security expert so I am asking for your advice.

This is the authentication flow:

  1. User types in email address
  2. client send email to API
  3. API creates User if not exists
  4. API generates a short living jwt with a UUID and saves the user id and session id as claims
  5. token id and session id get saved to db with a confirmed flag
  6. API sends this token to the email address
  7. User clicks the link on any device of choice
  8. if token is valid and the claims match the data in the db the confirmed flag is set to true and a last_login field is set to the token's iat (not really sure know if I need that ^^)
  9. Meanwhile the client where the user logged in polls for confirmation and updates session if login was confirmed
12
  • You have not described authentication. You're just linking the email to the session.
    – schroeder
    Jul 9, 2020 at 14:10
  • 1
    OAUTH is getting close to passwordless. I'd link your service to an OAUTH provider
    – schroeder
    Jul 9, 2020 at 14:13
  • 1
    You are not describing authentication, as I said. At best, you are authenticating the email account, not the user. This is 0.5-factor-authentication. I cannot change a password. And you are relying on the security of email transmissions and storage, which can be very exposed.
    – schroeder
    Jul 9, 2020 at 14:19
  • 2
    Take a look at magic.link again. It delegates auth to the email client. They are very clear about that. This is not authentication. This is "logging in". This is "gaining access". You push actual authentication and account security to the email client. You need to be very clear about that yourself. Is your service at a low level of sensitivity to have that make sense?
    – schroeder
    Jul 9, 2020 at 14:33
  • 1
    Ok, then I'm glad we got clear on that. PCI-DSS might have some things to say about a passwordless approach. I know we aren't talking about your login process, but I fear for your design not being fit-for-purpose even if it was secure.
    – schroeder
    Jul 9, 2020 at 14:52

2 Answers 2

1

If you rely only on the hability to access to the declared email address, I think you should have eavesdropping detection methods.

For example, in your current flow, if an evil E accesses to the mailbox after the owner, E can still click the link and be authenticated.
Also, every NSA router (so every router ^^) between your API and the user's mail server can read the token if the email is not encrypted (which is not only under your control).

So a "burn after using" should be implemented for the token.
So if the token is automatically eavesdropped and used before the legitimate user, he will see that someone took the access (because the token will be burned and his access will be refused). And if the token is acceded after the legitimate user, it has no value anymore.

So the authentication token, after been used, must be different from the session token used to maintain access for the user.

1
  • Most people these days are accessing email either through a web interface (which will be HTTPS), or preconfigured apps that will only dial to authenticated servers over some form of TLS. Specifically to prevent snooping, and because it's easier.. Jul 10, 2020 at 20:27
0

The process itself

What you described is more like a user creation process, I can't see where you are confirming the identity of the user.

If someone has the user's email password, it is game over, so, this may no be as passwordless as desired.

email security

Another point is that email protocols are not always secure, on the contrary, the default is to transmit emails in clear text from a server to another. The exception may be the user interfaces, which is preferred to use TLS (secure internet browsing), but all the rest is likely to go unencrypted. So, relying in email to replace passwords may not the best idea.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .