
Users don’t need a password - isauriy
https://medium.com/@SuperPaintman/your-users-dont-need-a-password-9e3fa492f69
======
zippergz
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.

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

~~~
yoz-y
Just?

Also, the only application that should have an actual access to your mail is
your client.

~~~
earenndil
Sure, it could hook into your email client. And it would be opensource.
Wouldn't have to be complicated, could even be CLI.

------
nickjj
Just throwing this out there:

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.

~~~
arve0
What about SMS? Would you use the service then? Genuinely wondering, I'm
planning passwordless logins for my users.

~~~
nickjj
No, but I'm also a huge edge case.

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.

------
mschuster91
Hmm. Problem with this approach, as with Sign in by FB/Twitter, is: what to do
when the provider bans you? People have complained since years that Google
takes down their entire account including mail for stuff like "violating
copyrights" on Youtube while being compliant to fair use (and then doesn't
even offer you to get your data!), and Facebook and Twitter are home to troll
squads abusing the "report" feature, which triggers automated anti-spam/troll
systems before a human actually can do a review.

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.

~~~
dingdongding
You solve a problem for 99% of cases not 1% of cases

~~~
mschuster91
True, but for those who _do_ experience a ban by any major SSO provider
they're straight outta luck. With FB/Twitter/Amazon SSO you can at least
contact the sites you're locked out from and provide your email address to
prove it's your account and hope the administrators actually have a workflow
to convert a SSO-bound account to a "normal" one - but not when the only
"proof" method is your mail address which is gone.

I always tend to think about the 1% edge cases, because these (and the
resulting bad press!) can be those with the biggest amount of time required in
customer service, and in addition they're hard to set up in a way that isn't
vulnerable to phishing.

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

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

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

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

[https://imgur.com/a/1D84F](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](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.

------
peterwwillis
What a password is: a key

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.

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

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

------
satysin
I like Microsoft's new login system.

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.

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

------
buro9
I use auth0.com configured with a few providers in a passwordless mode.

You can see it in action here:
[https://www.lfgss.com/](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).

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

------
tzs
A lot of people use an @their_isp email address. If they change ISPs they
change email addresses.

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.

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

------
JoshMnem
In practice, users seem to get confused and then send emails asking why they
can't just use passwords.

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.

~~~
jazoom
As a counter point, I've been running a service like this for 2 years. I had
one person mildly complain in the early days and the thousands that have
signed up after haven't said anything about it. Emails go through instantly
every time and they rarely get logged out.

I get a lot of feedback weekly but it's never about the signup/login process.

------
skybrian
This is more complicated than it looks.

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.

------
alex_young
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?

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

[edit: formulation]

------
productboy
We build apps/services for the healthcare space. Passwords are the numero uno
cause of friction for healthcare users - but not for healthcare staff. We've
experimented with a few password alternatives but haven't landed on any that:
\- Don't force users to take a second step after they've entered some identity
information in the first step. \- Is HIPAA compliant. There's no specific
requirement for passwords but the security standards are very high; need to be
audit proof.

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

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

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

------
cdubzzz
> Result

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

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

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

~~~
gruez
judging from the parent post

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

------
m-p-3
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.

------
professorTuring
The only problem of passwords is that the they are unsafe and mostly broken.

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.

------
pg_bot
If you care about independence and security your service should own all of the
authentication. Everyone wants to ditch the password, which IMO is a foolish
idea.

------
Lxr
Please don’t do this. I have used sites that do this and the inevitable 30
second delay in receiving the email is infuriating.

------
finchisko
You don't need password but you need a email. I say: "out of the frying pan
and into the fire".

------
chx
I have been logging into drupal.org like this for longer anyone is comfortable
remembering :)

------
savrajsingh
TLDR: slack magic link explained

------
amelius
It's 2017. Why can't I login with my smartwatch just yet?!

~~~
LyndsySimon
I'm still hoping for ubiquitous FIDO U2F support. Unfortunately, I still can't
even get it to work outside Chrome, and very few sites support it.

------
ikeboy
Email is not instant and was never intended to be. My domain emails get
forwarded to my main gmail and can take a half hour to show up.

This is a bad idea.

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

------
moltar
Slack does this on mobile.

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

------
earenndil
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?

