
Ask HN: Why not to use passwordless login? - ivanpashenko
Is there a reason why new services are not using passwordless login? (Type your email -- receive the code -- fill in the code)
======
cpburns2009
Why would I want to go through the hassle of requesting a new non-password to
be sent to my email, wait to receive my non-password, and then log in using
that non-password every single time I want to log in? I will happily let my
web-browser remember my password, or store it in a password manager if it
needs to be secured.

~~~
lewisl9029
Square Cash is the most prominent example I know of for an email-based
passwordless login system, and I personally really like it.

> then log in using that non-password every single time I want to log in?

The key piece of UX in these systems is you don't make the user do this _every
time_ , but rather only when logging in on new devices, and after a reasonable
expiration date, say 30 days.

For the average HN user, this might not be much of an improvement in terms of
security or UX compared to a regular password system when used with a good
password manager. The average internet user is and always will be much less
sophisticated, however, and is someone who can manage to regularly forget even
their really crappy passwords (if they use more than 1 password to begin
with).

For the average user, I think this system improves both UX and security by a
large degree because for UX, it removes the need to remember more than 1
password (the password to your email serves as your master password), and for
security, it verifies identity using the _ability to access_ an email and a
device (browser) rather than the mere _knowledge_ of an email and a password.

~~~
cpburns2009
This simply sounds like a forced password reset scheme which I don't see the
benefit of. Standard passwords can accomplish exactly the same thing with the
added advantage of allowing instant log-in if you remember your password.

------
BjoernKW
Plenty, both in terms of security and UX:

1.) It's less secure (unless the email is encrypted, which in most cases it is
not).

2.) If you use GMail with several accounts and POP3 you'll have to wait until
GMail sees fit to fetch the email.

3.) Password managers provide both a superior UX and superior security. So, by
all means at least provide a password-based login as an alternative (which
admittedly defeats the purpose for the operator to have a less complex
authentication system to worry about).

~~~
ngrilly
> It's less secure (unless the email is encrypted, which in most cases it is
> not)

I disagree. With opportunistic encryption, if the recipient' server supports
STARTTLS, then the communication between the sender' server and the recipient'
server is encrypted using TLS. Nowadays, all major email service providers
support STARTTLS.

> If you use GMail with several accounts and POP3 you'll have to wait until
> GMail sees fit to fetch the email.

Just use the GMail to avoid the delay with fetching third party accounts.

> Password managers provide both a superior UX and superior security. So, by
> all means at least provide a password-based login as an alternative (which
> admittedly defeats the purpose for the operator to have a less complex
> authentication system to worry about).

I mostly agree, but:

1/ Alas, most users don't use a password manager. They keep reusing the same
passwords on multiple websites, which is a serious security risk.

2/ If the user uses an email server that doesn't support STARTTLS, then
theoretically an attacker could request a password reset and "catch" the
unencrypted email.

My conclusion: Passwordless login is an interesting solution. But there are
other issues to consider, discussed in other comments (email delivery
latency/greylisting, ergonomy, need to remember which email address you used,
etc.).

~~~
stephenr
> I disagree. With opportunistic encryption, if the recipient' server supports
> STARTTLS, then the communication between the sender' server and the
> recipient' server is encrypted using TLS. Nowadays, all major email service
> providers support STARTLES.

With regular passwords via a browser, you can _ensure_ the channel is
encrypted via HTTPS.

Opportunistic encryption is exactly that: it uses encryption _if_ it can, but
will fallback to unencrypted if not.

How is "sometimes encrypted, if its available" not less secure than "always
encrypted, unavailable if encryption doesn't work"?

> Just use the GMail to avoid the delay with fetching third party accounts.

So, you're simultaneously suggesting that everyone use 'email links for login'
_and_ suggesting everyone use a single email provider? Sure, that doesn't
sound terrible at all.

> most users don't use a password manager

What's your basis for this? _Every_ browser in use today has a password
manager built in. People promoting these bullshit "not a password"
alternatives always claim "average people" don't use password managers, but
never present any evidence of that.

> If the user uses an email server that doesn't support STARTTLS, then
> theoretically an attacker could request a password reset and "catch" the
> unencrypted email.

Firstly - the main security concern with emailed 'login' links isn't the
transport at all - it's storage/accessibility via the mailbox. Breach the
mailbox, and you've breached the third party sites. The part people always
ignore when suggesting emailed links as an alternative, is that if an attacker
breaches your mailbox, they could conceivably use that to access your third
party service that uses login links, and the victim would never know, because
there is no password being reset, no killing of previous sessions.

> My conclusion: Passwordless login is an interesting solution. But there are
> other issues to consider, discussed in other comments (email delivery
> latency/greylisting, ergonomy, need to remember which email address you
> used, etc.).

My conclusion: password-less login is a thing that exists via public key
cryptography: see ssh, TLS client certificates. Emailing links to people is
nothing more than a fucking stupid idea, and frankly it's ridiculous that your
"other issues to consider" makes literally zero mention of any security
concerns.

~~~
ngrilly
> With regular passwords via a browser, you can ensure the channel is
> encrypted via HTTPS.

I agree. But there is still the issue of forgotten passwords and the infamous
password reset emails. How do secure them in the face of "opportunistic
encryption with STARTTLS"?

> So, you're simultaneously suggesting that everyone use 'email links for
> login' and suggesting everyone use a single email provider?

As I said in another comment, I was specifically answering to a sentence
starting with "If you use GMail with several accounts and POP3". My point
being, if you are already using GMail, then just use your GMail address to
avoid the delay in fetching other POP3 accounts.

But it's true that password login has the strong advantage over passwordless
login to let you login instantly if you (or your password manager) remember
your password.

> > most users don't use a password manager > What's your basis for this?
> Every browser in use today has a password manager built in. People promoting
> these bullshit "not a password" alternatives always claim "average people"
> don't use password managers, but never present any evidence of that.

My basis for this is that, year after year, I keep reading publications
showing that most users reuse the same password on multiple websites. Just
search for "password reuse statistics" and you'll find a lot of evidence:
[https://www.google.com/search?q=password+reuse+statistics](https://www.google.com/search?q=password+reuse+statistics).
"Average people" probably use the password manager built-in in their web
browser, but it doesn't necessarily solve the main issue which is password
reuse. Since you're asking for evidence, what evidence do you have to support
your own claims?

> Firstly - the main security concern with emailed 'login' links isn't the
> transport at all - it's storage/accessibility via the mailbox.

I agree. My mistake to emphasize attacks on the transport when the biggest
worry is the storage.

> The part people always ignore when suggesting emailed links as an
> alternative, is that if an attacker breaches your mailbox, they could
> conceivably use that to access your third party service that uses login
> links, and the victim would never know, because there is no password being
> reset, no killing of previous sessions.

This problem is not ignored. We can for example watch IP addresses used to
connect, and notify the user connecting on the "usual" IP that we have
detected another connection on a new/unseen IP. I'm not saying this is easy,
but this is probably solvable.

Moreover, I notice that most non-technical users around me, when they are
unable to connect because their password is refused, tend to think this is an
error on their side, and just reset the password, without thinking they could
have been hacked, which weakens your argument.

> My conclusion: password-less login is a thing that exists via public key
> cryptography: see ssh, TLS client certificates. Emailing links to people is
> nothing more than a fucking stupid idea, and frankly it's ridiculous that
> your "other issues to consider" makes literally zero mention of any security
> concerns.

A civilized discussion would be easier if you could avoid the words "fucking"
and "ridiculous". You're claiming that passwordless login ignores important
security concerns. I think that the human factor (forgotten passwords,
password reuse, etc.) is big in the list of security concerns, and
passwordless login can be an — imperfect — answer. That said, I agree that
using public key cryptography in the vein of ssh would be a lot better than
password and passwordless login combined.

~~~
stephenr
> I agree. But there is still the issue of forgotten passwords and the
> infamous password reset emails. How do secure them in the face of
> "opportunistic encryption with STARTTLS"?

Realistically, you can't without some secondary auth for password resets (i.e.
secret questions, a phone call, or things like 'send a message signed with
your public key' (which the service operator obviously needs to know
beforehand) - all of which are either easy to game, or not particularly user
friendly for the non-technical - but even without those options, the password
reset scenario still has one advantage over the 'login link' system: at the
very least the user will know the breach occurred, because they will a) lose
their current sessions and b) not be able to create new ones (due to the
password having changed).

> My point being, if you are already using Gmail, then just use your GMail
> address

There are plenty of reasons not to use the 'primary' email address of a system
which also offers pop3 download into webmail, and your response just
highlights how short sighted this "solution" is.

> "Average people" probably use the password manager built-in in their web
> browser, but it doesn't necessarily solve the main issue which is password
> reuse.

So if we agree that most people probably do use the built in password manager,
wouldn't a _better_ solution be, for the password manager, which _knows_ all
your passwords anyway, to take action, and suggest better passwords? "Hey, we
just noticed you logged in with a password that you've used on at least 389
other sites. That's not very secure, if you'd like to change your password for
this site, <Browser> can suggest a strong password, remember it for you and
sync it to your other devices too".

> Since you're asking for evidence, what evidence do you have to support your
> own claims?

You just admitted that average people probably use the password manager built-
in. It's pretty well observed now that non-technical people (and even
technical, in some situations) will blindly click "OK" or "Accept" or "Yes" to
whatever buttons appear on screen when they're trying to achieve something. I
don't have any evidence I can link to, just 14 years of anecdotal stories
about how people clicked "yes" to "do you really want to delete this now?" and
then call helpdesk because it deleted something, etc.

> This problem is not ignored.

It's never mentioned as part of the actual proposal, it's _always_ a "well you
could do X and then Y and then Z" and pushes responsibility to the USER to
determine if someone else is using their account.

> We can for example watch IP addresses used to connect, and notify the user
> connecting on the "usual" IP that we have detected another connection on a
> new/unseen IP.

a) most people barely know what an IP address is, much less what theirs is.
Even with GeoIP info, you _still_ have the risk of people being attached by
someone actually in, or spoofing, a close proximity. GeoIP info for my current
IP has recently changed to my current city, but recently showed me as being in
a city 70km away, with a population of 10M people.

> I'm not saying this is easy, but this is probably solvable.

So is a cure for Cancer but I'm not going holding my breath for that either.

> Moreover, I notice that most non-technical users around me, when they are
> unable to connect because their password is refused

A decent auth system would _notice_ two successive password resets in a short
span of time, and send a notice with the second one that a password reset was
_just_ performed <X> minutes/hours/days prior, with information to contact the
service provider if the earlier reset was _not_ initiated by the account
holder.

> A civilised discussion would be easier if you could avoid the words
> "fucking" and "ridiculous".

Maybe I should have changed the use of certain words, so let me be more clear:

The _idea_ is ridiculous:

    
    
        ridiculous |rɪˈdɪkjʊləs|
        adjective
        deserving or inviting derision or mockery; absurd
    

Discussing an authentication method and _not_ discussing the security concerns
is fucking stupid:

    
    
        fucking |ˈfʌkɪŋ|
        adjective [ attrib. ] & adverb [ as submodifier ] vulgar slang
        used for emphasis or to express anger, annoyance, contempt, or surprise
    
    
        stupid |ˈstjuːpɪd|
        adjective (stupider, stupidest)
        lacking intelligence or common sense
    
    

> You're claiming that passwordless login ignores important security concerns.
> I think that the human factor (forgotten passwords, password reuse, etc.) is
> big in the list of security concerns

Sure, this and every other concept for emailed links for auth addresses that
same single factor: people re-use, and forget passwords. I'm claiming that
every "passwordless" solution based on email login links I've seen,
conveniently ignores any problem their "new" idea introduces, some of which
I've highlighted above.

Some like Homakov go a step further: when I suggested that his version of this
concept is insecure because mailboxes aren't secure, his response was
literally "Yeah but I'm not trying to solve the whole problem". Right. Well
I've got a great cure for an ingrown toe-nail: I'll cut off your leg. You
won't be able to walk, but I'm not trying to solve the _whole_ problem.

------
pavel_lishin
As a consumer of services, it's not more convenient for me than clicking the
Lastpass (or your password manager of choice) icon and filling in the login
form.

Plus, I imagine some people may have multiple email accounts, and would have
to hunt through them to figure out which one they used to sign up with.

(Similar to my problem with StackOverflow; I can _never_ remember which
identity provider I used to sign up with them, and end up just clicking on all
of them in order until one lets me in. For all I know, I might have multiple
accounts.)

~~~
shanecleveland
Not saying your are wrong in your preference, but you can similarly use a
password manager to save the email address used for a password-less login. So
perhaps not a good argument against passwordless logins in general, though I
am sure there are many good reasons against it.

So far, the few arguments against here are individual, convenience-based
reasons. Those are certainly valid reasons, because if you inconvenience a
potential user, they may never become an actual user.

Not everyone has a password manager, and many people use the same username,
email and password across many services. The larger danger can be that if one
service is hacked, it may provide a hacker access to many services, including
email. A provider of a service with a passwordless login would never have to
worry about being the root cause of such a breach. And, as long as the users'
email was not hacked, would not be susceptible to malicious activity through
another hacked service.

One question for the OP: What kind of service are we talking about? If the
information is sensitive, then perhaps it is not a good idea. If it would be
safe to keep a user logged-in after a session ends, then maybe a good
consideration. By limiting the number of login requests, then you reduce the
inconvenience.

~~~
pavel_lishin
> _you can similarly use a password manager to save the email address used for
> a password-less login_

Sure, but it still adds an extra step; my current manager doesn't have a "log
into the email address you used to register with this site" button.

But you're right, there are advantages to email-based login.

~~~
shanecleveland
You're right about that extra step, which may be crippling enough to keep
users away.

------
marssaxman
That's just the "forgot password" system, minus the convenient option of
entering a password instead of waiting... and waiting... and waiting... and
checking your spam folder... and waiting some more... for the email with the
auth code to arrive. Not actually an advantage, in my eyes.

------
mattbgates
While passwords are still my preferred method, I was trying to think about
ways to incorporate a passwordless system.

I like the method that Slack has.. while they offer the old method of logging
in with a password, their other method is to send your email a link and then
once that link is clicked, they set a cookie indefinitely.

The other way is once a user registers for an account, they get an email to
login, but before they can login, they have to enter in their phone number, so
then from then on out, every time they enter in their email, they will get
sent a text message and simply have to enter in a code.

It is still not technically passwordless, but it certainly is a unique method
to have people login.

No matter how far we come though, the username and password seem to still be
our best method of knowing WHO YOU ARE and verifying the account belongs to
you.

------
Scaevolus
I think OAuth logins are a nice compromise. "Login with Google / Facebook /
..." with one click works well!

Unfortunately, some sites use it to just get your email address, and _still_
require you to make a password for them, which defeats the purpose and
decreases user trust in the benefits of going through the flow.

~~~
joshontheweb
This can be pretty annoying for users and developers though. If the user
forgets what account they last used and selects a different one next time then
it ends up creating an entirely new account unassociated with the first. If I
ever do social integration, I require a plain old email based login first and
then allow them to connect their social accounts to it.

~~~
lewisl9029
One way around this (from the developer's side) is to federate together
different identities for a user using something like dex [1], and segregating
your login and signup paths, so attempts to login will never create a separate
account.

[1] [https://github.com/coreos/dex](https://github.com/coreos/dex)

------
cuu508
> Type your email -- receive the code -- fill in the code

Many services actually do support this. It's under "Forgot Password..." link
when signing in ;-)

~~~
shanecleveland
Exactly. I choose to forget my password in many cases.

------
antaviana
Email deliverabilty is not necessarily 100%. Also there can be latencies here
and there that can lead to user frustration (for example greylist strategies).

One alternative for password-less is to use Google Authenticator code as the
password (i.e. send the QR code once by email and from then on use the Google
Authenticator code), but I'm not sure if the the low entropy (1/1000000th
chance of guessing the right password) would be enough for brute force
attacks.

------
Lan
Consider the three most common authentication factors:

* Something you know

* Something you have

* Something you are

A conventional password-based login implements "something you know" (i.e. your
password). A password-less login implements "something you have" (e.g. email
access). That doesn't make it more secure, it's just substituting one
authentication factor for another. One could argue that it's more convenient
but that's subjective since people that use password lockers might actually
find it less convenient.

An argument against password-less logins might be that they should be
implementing multi-factor authentication in the first place. Password-less
login is by nature not at least two-factor authentication. Even if you have
two-factor authentication enabled for your email, it will still just be
"something you have" because someone that gains access to your PC or phone
will probably have access to your email as well. The easiest second factor to
add into the mix is "something you know" (e.g. a password) and now you're back
to conventional two-factor authentication practices.

------
lwlml
It is a cultural problem. I think the "younger" users don't use e-mail as much
as they do other forms of "Internet" e.g. Facebook for authentication.
Otherwise, I'm loathe to give out my e-mail address because of spamming and
data-collection.

------
tmnvix
Greylisting[0] would still be a problem. Signup is exactly the situation where
this would be both most likely and most inconvenient.

[0]
[https://en.wikipedia.org/wiki/Greylisting](https://en.wikipedia.org/wiki/Greylisting)

------
nkkollaw
I would think, because that's a nightmare versus both social login and my
browser remembering both username and password..?

That's way too many steps, and takes too long since many times email takes a
while to get fetched—specially on mobile.

------
ngrilly
The main issue with passwords is that non-technical users tend to reuse the
same password, which is a serious security risk. This is, in my opinion, the
best reason to use a passwordless login. A better solution would be, when the
user create his/her account or reset his/her password, to generate a random
password, instead of letting the user choose a password. I'm curious about
this approach. As anyone tried something similar?

------
zzo38computer
I don't like those "login with Google / Facebook / etc", nor that "Type your
email -- receive the code -- fill in the code". OpenID would be better I
think. You can design it to use something other than a password for
authentication if you want to; it mean the authentication system can be
independent from whatever you log in to.

------
stephenr
why _would_ they? It's less secure, and less usable.

------
Tomte
I liked the way The Magazine worked: they sent you a link which set a cookie.

------
theandrewbailey
It's exchanging one authentication factor (something you know) with another
(something you have), while negatively impacting UX (by adding email UX
issues) and not adding meaningful security.

------
assafmo
I think passwordless is better. webtask.io does this and it's awesome.

