That's a good point, but there's plenty of services which are only used occasionally. For example, I practically never log into my domain admin panel - and as a result, before I started using a password manager, I'd wind up forgetting my password every time I needed to use it.
Conversely, for certain types of sites (medium being one), I'm more likely to sign up if I don't have to generate and store a new password. Even with a password manager it's a lot more friction than entering an email then clicking a link.
It takes a legit 3 seconds to make an initial new password for a site and then accessing it requires running `pass Sites/medium.com -c" which copies the password to my clipboard for 45 seconds.
I don't even know what most of my passwords are because for the last few months I've started to use its built in feature to generate passwords that get past 99.9% of arbitrary password rules that a lot of sites enforce.
There's a line and it depends on frequency of usage. If I login at least once a week, I will remember my password. There are, however, plenty of systems that I log in to far less frequently and consequently reset my password every single time. Reset requires an email confirmation. In that case, using the email link as the authentication is just steering into the skid.
Edit: I'd also suggest it's pretty easy to support either option for users with different levels of engagement.
But how many times do you actually have to log in? Depending on the site, you may never want to log out. So a login event can and probably should be very rare for most sites.
I don't use a smartphone. My non-smartphone does have an unlimited texting plan but I rarely keep my phone in the same room as me when actively using my workstation.
Mainly because when I'm in work mode, I put the horse rudders on and try to eliminate as many distractions as possible but also cell phones are known for creating line noise in audio equipment and part of what I do requires recording a lot of audio.
The tl;Dr of this article is to email a one time login link to your users instead of having them enter a password, similar to how you reset a password on most sites.
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.
Since you mention Persona: There is portier[0], a successor project (I'm part of the project). Login via email as default, or via your Google account for gmail addresses, and other email domains could use their own login system.
I personally love the idea of having users log in with a temporary token sent by email, and have been doing so in my own projects for a while now.
However, I don't think sending them a link is a good idea, since it just gets them used to clicking on things in their emails, which could potentially lead them being phished quite easily.
You make a fair point against sending links in emails, so how do you implement the token in the email? I'd like to start doing that in my own projects too.
If you don’t want your users to have to supply a password, then just use OAUTH and let them log in with their Google, Facebook or other common ID. Checking a “magic link” every time I want to log in is a huge pain, especially on mobile.
I just did this with my web app that helps you track alt coin earnings. Just enter your wallet addresses and then bookmark the unique url that's generated for you. Access any time with no credentials. Works well so far but might not be best for every app.
Using the URL as an authentication token is something different and has some insidious security properies for all the various ways that URLs can leak.
At the very least you must place the token after the '#' in the URL, disable Google crawling in robots and turn off certain indexing modes using Webmaster tools.
>[...] that helps you track alt coin earnings. Just enter your wallet addresses [...]
makes me think that the it's view-only anyways. even if you got a hold of the wallet address (authentication token), it's not like you can redirect the payout to somewhere else. and while it's true you can see another user's earnings, that information is publicly available on the blockchain anyways.
I don't store any personal information. Just public chaincoin wallet addresses so I think in my use case this solution works pretty well. Good ideas to think about though! :)
While we all see this as the glaring pain point, it is only because we are conditioned to a current way of logging in. Also this is the point of the token stored in cookie storage, the practice used by any large, average user focused company (Facebook/Twitter/Google services). The tokens and session keep them logged in, they hardly ever log in again.
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 would rather store the token in Redis, so that I can take advantage of its expiration functionality. Additionally, load is removed from the database and it provides faster lookups. I would, in addition, also cache the session data (e.g. the row from the user table) in Redis.
From a usability standpoint, I feel that this just trades one set of issues for another.
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.
Just make an app that automatically connects to your email, gets and parses the email (there can be a specific format) and asks "would you like to sign in to slack?" And you can just press "ok" and you'll get in. To make it even better, you can make it so that the email is signed by a pgp key you've previously trusted ("would you like to sign into trusted provider 'slack'?"), to make it resilient against phishing emails, and for extra protection the slack sign in page can show a random series of 6 digits, which is also emailed to you, so a phishing email wouldn't have access to those 6 digits; and you can compare those to what the app shows you.
I had been prepared to make a comment saying that the article's proposed flow is essentially the same as oAuth, except your email service acts as your identity provider and it is all manual.
But I have a feeling you may be facetiously getting at the same thing. Or are you?
Don't know about 1Password but bitwarden[0] has an auto-fill service for native apps which works great on Android in my experience. A simple slide down to open the notifications then two taps to select the details to use and it does the rest without having to leave the main application. Much faster than typing in my username and password.
The only iOS app I can recall that integrates with 1Password is HipChat. Integration requires using AgileBits' extension (https://github.com/AgileBits/onepassword-app-extension). The password manager doesn't have any OS-level hooks that allow it to work with any app.
This is no longer true in iOS 11 (and may have been true in iOS 10). Programs may opt into showing “secure” share extensions in the same way that has been in Safari since share extensions were introduced.
I've been using bitwarden for a few months now, and it has totally supplanted LastPass in my workflow.
The only thing I miss is LastPass's form fill capability, but so far that's not been a huge barrier; trusting my browser to keep my credit card and address information handy and relatively safe isn't as convenient, but it's acceptable.
But this is really only needed sometimes. Most of the time you don’t need to log in at all. I’ve asked myself for years why not all sotes use this solution, it seems so obviously superior.
This model works great when the vast majority of the interaction on your site has no need for a persisted session.
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.
Having to access private email to log in somewhere is a huge pain for me when on some networks, e.g uni with only http/s proxy and no IMAP so I can't even check my email when on Wi-Fi.
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).
I agree. I used to have a similar setup, where my <firstname>@<firstname><lastname>.com address forwarded to Gmail, and even then things were sometimes slow. I've recently moved to forwarding to <firstname><lastname>@protonmail.com, and now it takes even longer for things to come through.
This better not be advice for a service I'd like to use frequently, because if I had to open my email inbox every single time, I'd just not use it. Those "unrecognized device" notifications that pollute my inbox from Twitter made me not use Twitter (I've elaborated on this in the past), let alone having to open my inbox before being able to use the site. And no, it won't be able to remember^W track me because cookies are deleted automatically.
I'd much rather just have an option to use a username and password using my password manager, thank you.
What happens when the user returns? Do they need another email or do you leave the session around forever?
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?
Everyone here is complaining about how they don't want to have to check their email every time they sign in. Why not just make an app that sits in front of your email, scans for emails of the form 'sign in email,' and when it finds them provides a single button for you to press to sign in?
Medium uses this login method and I think it's super cumbersome.
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...
I prefer the OAuth way of authenticating. Let me secure the primary account, and federate the authentication with them. Less passwords to remember, and the OAuth token can be revoked in case of a security breach.
We've been using a variation of this for the "customer dashboard" part of the website (we make desktop software).
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.
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:
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.
> 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?
I'm generally a fan of this method and have picked it for a couple of projects in the past. With relatively long session lifetimes, the UX is acceptable for many use-cases.
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.
One concern. If there is a data breach with my email provider (like it did in Yahoo), I may not have a way to change my email in the App if the attacker changes password to my email.
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.
77 comments
[ 3.1 ms ] story [ 37.6 ms ] threadI 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.
Then both types of users are happy.
Most of the time I need to log into your random service I'm doing a password reset anyways
I like using pass[0].
It takes a legit 3 seconds to make an initial new password for a site and then accessing it requires running `pass Sites/medium.com -c" which copies the password to my clipboard for 45 seconds.
I don't even know what most of my passwords are because for the last few months I've started to use its built in feature to generate passwords that get past 99.9% of arbitrary password rules that a lot of sites enforce.
[0]: https://www.passwordstore.org/
Not if it means having to check your email and wait for it to arrive.
Edit: I'd also suggest it's pretty easy to support either option for users with different levels of engagement.
> You can give a cookie to user.
I suppose that once you logged in with a device, the idea is to keep you logged in.
I don't use a smartphone. My non-smartphone does have an unlimited texting plan but I rarely keep my phone in the same room as me when actively using my workstation.
Mainly because when I'm in work mode, I put the horse rudders on and try to eliminate as many distractions as possible but also cell phones are known for creating line noise in audio equipment and part of what I do requires recording a lot of audio.
I frequently don't have cell coverage but do have WiFi.
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.
[0]: https://portier.github.io/
At the very least you must place the token after the '#' in the URL, disable Google crawling in robots and turn off certain indexing modes using Webmaster tools.
>[...] that helps you track alt coin earnings. Just enter your wallet addresses [...]
makes me think that the it's view-only anyways. even if you got a hold of the wallet address (authentication token), it's not like you can redirect the payout to somewhere else. and while it's true you can see another user's earnings, that information is publicly available on the blockchain anyways.
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
[edit: formulation]
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.
Also, the only application that should have an actual access to your mail is your client.
But I have a feeling you may be facetiously getting at the same thing. Or are you?
[0]https://bitwarden.com
The only thing I miss is LastPass's form fill capability, but so far that's not been a huge barrier; trusting my browser to keep my credit card and address information handy and relatively safe isn't as convenient, but it's acceptable.
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.
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).
This is a bad idea.
I'd much rather just have an option to use a username and password using my password manager, thank you.
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?
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...
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.
> 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?
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.
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.