Users don’t need a password

Instead of having to remember a password, now I have to break my flow, go into my email client, and wait for an email to arrive. I have actually tried this flow with Slack's "Magic Sign-in Links." In my experience, it is not uncommon for it to take a few minutes for an email to arrive. In some cases, that could be enough to make me give up and move on. (I do appreciate Slack's approach to this -- you can choose to either use your email/password OR the emailed link). The thing is, the first usability problem (remembering passwords) is one that I can easily fix on my own if I so choose (either via a password manager or, heaven forbid, letting the browser remember it). The second (having to wait for an email) is totally out of my control.

That said, the one place where passwords are still a major hassle is in native mobile apps that don't integrate with a password manager. I still think that bouncing out to 1Password and copying/pasting my password is overall preferable to waiting for a link in email, but it's far from ideal.

I won't use your service (no matter how good it is) if I had to check my email and click a link every time I wanted to login.

What's worse: Google, Amazon (yeah they ALSO act as a SSO provider!), Facebook and Twitter offer their users no way of appeal or even contact with a human in case of a ban, and not even when you get a lawyer to write a nasty letter to them. In contrast, regulated telcos (in Germany) have very strict requirements on when they're allowed to kick off customers. Time to regulate the giants in the same way, given their importance to not just communication across society, but also due to their growing SSO power.

The main reason sites don't this is because it's a bit user unfriendly. I think a reasonable compromise is to use login with Facebook or Google so you never have to worry about passwords. There are downsides of course (user privacy concerns, dependent on third party platform), but since Persona never took off I think it's the best option. When I ran a user facing webapp I offered signing up with email/password as well as social network login, but encouraged people to use the latter.

The login page defaults to "email me a login link", but once they get in, the customer is given an option to set up a password. If they do, we drop a cookie and then the login page defaults to the password-based form. If they don't, they keep seeing an email-based form.

https://imgur.com/a/1D84F

The bonus part is that the "Forgot the password" form is essentially the same as "Email me the link", so it's possible to pack all three variations of the form into a single page:

https://i.imgur.com/kBNBsd0.gif - pardon the ghosting, it's a gif encoding artifact.

We had this up for a couple of years now and it works really well.

Why we use a short text key: to keep it [most of the time] in meatspace, outside the domain of most attackers

What email tokens are: temporary keys

Why we don't use them: 1) they don't work offline 2) they require access to multiple networks 3) they can be intercepted easily 4) delivery is not efficient or guaranteed 5) they can be used for parallel attacks

Many sites don't control use of email tokens with things like security questions or a second factor, which makes it easy to use email as an invisible vector of attack. If you're going to remove passwords you need some additional authentication methods.

I'd much rather just have an option to use a username and password using my password manager, thank you.

If you are a power user that uses a 2 Factor auth, you have already decided you do not mind a "non traditional" way of accessing a service. As an example, logging into AWS takes an extremely long time: 1. pull out a separate device 2. open an app 3. finally enter a set of number (god forbid you do it as it expires). This is far slower than simply opening a new tab / switching to the already open tab or application of a mail client and clicking on a link.

This solution only becomes an issue for power users when they personally decide against storing non tracking cookies and allowing sessions.

I would also suggest 2 improvements: 1. JWT such that it is not stored in the database 2. If the front end application detects that the token is expired, either refresh the token or begin triggering the email confirmation process

EDIT: I do not think this is the best solution, but it could be viable

I enter my account email then it gives me a unique number related to that login attempt. On my phone it gives me a prompt (via their Authenticator app) to select the correct number out of three choices.

It isn't perfect but it is better than some generic "do you approve this login? yes/no" prompt.

Of course if my phone isn't available I can still login with a password.

One thing worth pointing out is that the algorithm as described allows for a timing attack on the sign-in token. A common mitigation to this would be to do the database lookup using a different key (the email address, primary key or any other unique value that's not related to the actual token) and then use a constant time string comparison algorithm to compare the tokens. Another best-practice would be to store a hash of the token rather than the token itself. This reduces the impact of a leaked database dump, where a copy of the database is stolen (think: public S3 bucket), but no (write) access to the database is gained.

This is a relatively low-priority issue, but it's an easy fix, so probably worth considering.

You can see it in action here: https://www.lfgss.com/

For most users this is one-click after the first sign-in, and only a couple of clicks that first time. If they can't do this, it's the email code flow.

It works brilliantly, and no provider can disappear in a way that cripples my site. I only have to verify a user owns an email address and I'm back up and working.

I love this. I know nothing that puts me at risk beyond the email address, which I need for operational reasons anyway (it's a forum, notifications get sent via email).

You'll need to have a way for such people to roll their accounts over to their new email address, and you cannot assume that there is ever a time when they simultaneously know the new address and have access to email sent to the old address.

A lot of people won't even remember that they need to change their email address on your site until after the old address is completely dead.

At a minimum, you probably should allow them to associate two email addresses with their account, and urge them to make one of those email addresses be at a provider other than their ISP.

Login + password is just so much more convenient. Even 2FA with an authenticator app feels miles faster and more satisfying than this awkward go to your inbox, wait and click...

Example edge case: it doesn't work well for people who do things like sign up for your site with a secondary email address, and then try to access your site from a computer/device that doesn't have access to the secondary email account.

I think that Slack does it the ideal way -- you set a password, but you can always request a "magic link" to get into your account via an email link if you don't have easy access to your password.

It's a pain to log in each time. Solution: arrange so the user never has to log out of your website on the computer they normally use.

However, that assumes their computer is secure. If the threat model is a roommate accessing their computer, they need to secure it a different way (like always locking the screen).

So this gets into issues of how computer-savvy your users are and what their living situation is.

There are also people who don't have email accounts.

If you leave the session, what prevents an attacker from grabbing your cookies that one time you leave your system unlocked?

What about accessing the account from another machine? Do you then need another email each time? Does that access invalidate the tokens associated with other machines, or do you just keep proliferating tokens?

[edit: formulation]

My sense is a bioID is where we're headed. This year feels like the beginning of the end of the password era.

If you can provide your value with an unauthenticated session (which is different than no session at all) most of the time, but only relatively rarely need an authenticated/non-volatile session then by all means try this.

Of course if you do try it, you still want to give users the option of a password authentication versus email link.

Step 1 enter email, Step 2 enter password or click button to get a code.

But I think if more than 10% of the active sessions on your site are authenticated right now, don't bother with this.

> 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.

I wouldn’t call that a “result”. Does anyone know of examples where a system like this has been used successfully?

Having said that, it is the easiest tool to "identify" a regular Joe in a regular web.

All non-regular-more-secure webs should use 2FA.

This is a bad idea.

I have worked at places that use outlook/gmail so they block gmail/outlook for workers (yes, I've encountered both at 2 diff workplaces).