Passwordless Authentication in Phoenix

Nice post!

A feedback (or more like a question): from a security point of view, would it be better not to let the user know whether or not the email is found on the DB? Just notify the user as if the email were successfully sent, but silently swallow the error on the server-side (you don’t actually send the email). That way any potential attacker wouldn’t be able to guess who’s registered on your system.

UX-wise it would pose a problem if the user mistype their email, but that can be circumvented by just printing back the email to the client (“We have sent a magic login link to foo@bar.com. See you soon!”).

But of course implementing it this way doesn’t mean you can left out the maximum number of tries validation (and possibly captchas) for preventing brute-force attacks and using your system as spam mail generator

Thanks for the feedback! Good point, I’ll work that in!

Np, as a passwordless authentication fan, it’s great to see tutorials like this. Let’s strive to make passwords obsolete if we can help it

I don’t use passwordless authentication (yet!) but 99% of the time my errors are similar to this: “Wrong password / email combination” when one of the two are wrong. I try to keep them as simple as possible so no information are given to possible hackers who might try to brute force their way in.

fyi I updated the article incorporating your idea and mentioning this thread – thanks again!

Thanks for the tutorial, I’m still trying to work out whether I want to use this in my app, for the following reasons:

1. Is it easier for most people to check email to sign-in each time (or am I missing something)?

2. Is it significantly more secure - to save user profiles etc, a user account still needs to be created and checked against for creating sessions between logins, which will always have some login info stored eg email address if not password?

3. Is there a better way - eg as much as a developer may prefer not to use it, is signing in via Facebook etc the more practical version of passwordless authentication?

Perhaps, giving the user a choice to do one or the other or both would be best - log in by email link or password, whichever is most convenient at the time?

I’d stick with either email link or regular login and password you can augment both with supporting whatever other options make sense for your situation e.g. FB, Twitter, GitHub

It is presumably easier than remembering passwords (needs more research though). What’s worse is that most people don’t know the existence of password managers, so you end up with reused passwords across sites. In essence, passwordless auth is just a revamped forgot-password feature

Hmm, I don’t think I understand the question. But yes you need to provide email address for logging in (just as it is on @dennisreimann’s post). The security of saving user details on DB seems a different problem altogether

Social logins are also a form of passwordless auth for your app. However I know a number of people that mind using their social account for signing into a service.

This is as far as I know what Slack does. They still accept passwords, but encourage the user (at least on mobile) to use the magic links.

I would like to remind you all that email is an unsafe medium. You’re not sending electronic letters, you’re sending electronic postcards.
When you send a ‘forgot password’ email, it can normally only be used to reset a password once. On top of that, the better services also time these links out after a few hours.

With magic links, people will get grumpy if you time their old link out, so all old links should continue working for a very long time.

But in both cases, I have the feeling that too much trust is put in the medium that is email. But solving this problem is a bit a chicken-and-egg problem, as techniques like PGP are somewhat of a hassle to set up and need a password themselves.

I think we might leave the actual intent of the article/guide: Of course there are considerations, trade-offs etc. involved, as its the case with any kind of authentication.

My goal was neither to propose passwordless authentication as the one-size fits all or best solution nor to give an overview of all available options and compare them. The guide is for people who decided that passwordless auth is a good fit for their case or that are considering it and would like to see what a potential implementation might look like. I hope it helps these people to decide whether or not it might be a good solution – maybe also as a supplement to other kinds of authentication.

There are lots of good resources out there for comparing the available options and a few of them are linked in the article.