
Password-less login - im_dario
https://medium.com/findworkco/password-less-login-df0354c3f3ee#.gutdzrjjj
======
jlgaddis
> _Claim: If someone has access to email account, then they can login._

> _Rebuttal: This is possible in a password-ful login setup via the forgot
> password flow. Sometimes there are additional “security questions” but this
> is typically easily found information._

The difference here is that if/when someone uses their (unauthorized) access
to my e-mail account to reset the password for this service, I will notice the
next time I attempt to log in.

In an ideal world, one could _prevent_ another from gaining access to an
account, service, etc. When you can't prevent something, the next best thing
is _detection_. Here, you've just removed the ability for a user to detect
that their account is compromised -- and worse, you're trying to spin it like
it's a good thing.

Also, greylisting.

Also, what if I wanted to log in to my account from my phone or a mobile
device? I choose not to receive e-mail on my phone (only alerts/notifications)
and I'm certainly not the only one.

It sounds like someone pitched this idea at a meeting ("Hey, I know! No
passwords!") and the next 10 minutes was spent rationalizing all its problems
away before declaring it as the one true solution.

~~~
demonshreder
>The difference here is that if/when someone uses their (unauthorized) access
to my e-mail account to reset the password for this service, I will notice the
next time I attempt to log in.

I am assuming the indicator would be an email from a service stating password
reset but if the person has access to your email account, the obvious thing to
do would be delete such an email. There is no difference.

Passwordless login is basically piggy backing on the security of the email
account. You'd have to login to a site anyway but you are just logging in to
your email which is assumed to be protected better.

~~~
jswny
I think OP meant that he will clearly realize if someone used his email
account to reset his password because next time he tries to log in his old
password will no longer work. However with passwordless authentication,
someone with access to your email account could issue your account for
potentially a long period of time without you noticing. You would still be
under the impression that your account is secure.

------
scbrg
Con: Greylisting.

My primary email uses greylisting to combat spam. This means that if we
receive a mail from an unfamiliar mail server, it's getting an error message
saying the mail can not be delivered at the moment, and to come back later.
Properly configured servers try again several minutes later. Spam bots seldom
try again, so it works well.

I can see how greylisting and tokens that expire quickly can be a problem.
Particularly if you have multiple servers for outgoing mails, so that the
second mail attempt may come from another IP than the first.

~~~
abricot
I'd say that this is a con for graylisting, and not for passwordless access.

~~~
2T1Qka0rEiPr
Or at least, for both.

------
mherrmann
> You can't leak passwords if you don't store passwords.

That's exactly why you only store password hashes in the DB. Come on, this is
a solved problem!

> Pro: less implementation effort

Sure. But how much of your app's total dev effort is it? Nothing.

I hate the UX of having to log in by email.

~~~
gkya
>> You can't leak passwords if you don't store passwords.

> That's exactly why you only store password hashes in the DB. Come on, this
> is a solved problem!

Isn't leaking hashes dangerous for the users' privacy though (I'm not well-
versed in security, so sorry if n00b question)?

~~~
mhluongo
Not if you salt and choose a strong hash algorithm. Salting is what keeps a
leaked hash from hurting a user's security

~~~
gkya
Though if I have the user name and the salted hash and also access to the
service providers system, can't I use those to initiate a session? I mean
getting the cleartext password allows me to start a session through the UI and
also try to penetrate the user's other accounts elsewhere (maybe they reused
the password), but if I have the salted hash and access to the sytem, I'm
still able to get a session there, no?

~~~
mhluongo
Salting is to cover password reuse across services. If you already have the
keys to the kingdom for a service you can almost certainly access a user's
session

------
PuffinBlue
This implementation is just skipping the charade that passwords are where the
security happens.

With almost all current systems the place security really needs to happen is
at the email provider. If you can hijack/intercept a users email or hack their
account then it's game over with a password anyway, thanks to password resets
being (almost) universally done over that channel.

There's an argument that this is no bad thing as security focused email
providers could potentially provide very secure access as part of their core
business (unlike a startup just trying to get going).

But there's still something bugging me about this implementation I can't put
my finger on.

~~~
danijelb
The only thing that's bothering me is that it is done through e-mail. I would
prefer the token to arrive as a text message to my phone number. I feel like
it is safer and faster. However, I understand that it is more expensive
option, especially for services where you need to log in multiple times,
compared to mobile apps where you log in only once.

~~~
consp
SMS (in it's classical form) is highly spoofable as has been proven with TAN
codes time-and-time again. It will work most of the time (sms has no guarantee
of delivery as far as I know) and is somewhat secure but by no means good in
any way.

This relies on email, which is highly secure, smtp is not spoof-able, server
and mail origins are traceable and verifiable and there is no way to intercept
the message on a malicious router/switch whatever. Ow wait ...

------
jpttsn
I built (essentially) this a few weeks back, for an iOS app. Currently trying
to get Apple's App Review team to agree it's a good idea.

Apple has UI in App Store submission that lets you provide App Review with a
demo account username/password combo, but only that.

So to highlight another drawback: sometimes being able to share login
credentials is a feature. Part of me thinks this ought not to be the case, and
I hope I will be able to stick with password-less login.

~~~
wingerlang
Can't you just whitelist some token for them? If the sharing is the issue
you're having with them anyway.

~~~
jpttsn
I'm looking at that. I don't know what email they will use to test, and I
don't know if they'll look kindly at a special case for reviewers. Do you have
any experience with that?

------
susw
Is it really necessary that the email link is clicked on the same device or to
use a typeable token? Clicking the link on any device is enough to confirm to
the server that the login attempt should be granted access. The server can
then send and authentication token to the browser where the user is logging
in.

The downsides I can think of in that case are an attacker attempting to log in
at the same time, or -- more generally -- a user thoughtlessly clicking the
link when an attacker is trying to log in.

The first problem can be addressed by displaying a second readable token on
the login screen which the user should verify is present in the email before
they click the link. That is how banks and other high security systems do it
here in Norway now when you select authentication via mobile, except they use
some sort of mobile communication tied to the sim card instead of email. You
get a popup on your phone containing two random words from a dictionary. You
confirm that the words match what the browser is currently displaying and then
tap "OK".

The second problem can probably be reduced by short token timeouts and using
appropriate language in the email to emphasize the implication of clicking the
link uncritically.

------
ss64
cons: If the customers email service goes down, then their access goes down.
If your email service goes down, then the service goes down for everyone. If a
major email provider is compromised, then a bunch of your accounts can be
compromised. All public server-to-server email communication takes place over
port 25, unsecurred clear text. That seems like a poor choice for anything
security related in 2017.

If anything we should be removing insecure protocols like email, telephone and
SMS from the authentication chain rather than relying on them even more
heavily than we already do.

I hate to suggest it but authentication via something like WhatsApp might be
more secure.

~~~
NoGravitas
Server-to-server email is mostly STARTTLS (but without certificate validation)
these days, I believe. Not great, but better than you think.

------
herghost
An interesting idea for a few reasons.

Users don't have to remember passwords, which is a strong benefit, but the
user's security is now dependent on the security of their mail provider, or
their own security practices in relation to the use of that mail provider, and
in all likeliness their smart device.

With the ubiquity of smart devices, this works from a UX point of view and
could be really streamlined, but I wonder how much the meme at the top of the
article is actually betraying - this is the service provider not wanting to be
responsible for your security in relation to their service.

I'm not suggesting that this is unreasonable per se, but the ultimate
evolution of this model looks like it could (potentially dangerously) increase
the value of a smaller surface area (the smart device) and put a fairly huge
onus on the end user understanding and being responsible for their security.

And whilst that seems ostensibly ok, we already _know_ that the weakest link
in security is the end user...so this could be putting all your eggs in one
basket.

~~~
askafriend
> but the user's security is now dependent on the security of their mail
> provider

Let me put it this way. In many (but not all) cases I would much rather Google
be responsible for my security rather than some random startup whose primary
objective is to stay alive, not take security seriously.

~~~
subkamran
It's funny you say that because I feel the same way as a developer. However,
users of my site wanted password-based logins even though I support multiple
social logins (Google, FB, Microsoft, etc.). Granted, I use PBKDF2 salting and
hashing and I take security seriously, but it's interesting how average people
sometimes don't trust social providers or think I'm storing their credentials
to that provider.

------
grav
Password-less login is a bit of a weird naming. I'd call it one-time
passwords. And then I'd maybe not use email, since this clutters the inbox.
Instead something like Google Authenticator or SMS passwords would be a good
solution, the latter maybe being a bit expensive for the service provider.

~~~
Freak_NL
That would make having an SMS-capable phone nearby a hard requirement to
simply login to some service. I am fine with offering additional
authentication methods — if they are safe enough for that application — but
dismissing passwords as a concept (unless you are scaling up to proper 2FA,
e.g., Fido U2F) just means losing users for no good reason.

------
zbuf
You can easily leak whether someone has an account on your website -- if I
know their email address and input it, does it basically tell me? This limits
your ability to reasonably error if the email address inputted is wrong.

Still, a lot of "forgot password" forms seem to be subject to this, too.

Also, you can only have one account per-email -- a disadvantage for some types
of service, but admittedly probably a good thing for most.

------
danijelb
This is similar to what Whatsapp (and some other apps) are doing. The only
difference is that they are using phone numbers.

------
mike-cardwell
Loosely related. Why doesn't my web browser speak IMAP? If I could just enter
my IMAP details into my browser settings, then it could silently IDLE on my
Inbox, and inform my currently open [http://example.com/](http://example.com/)
tabs when it receives email from an @example.com address.

You'd need to stick it behind a "This website wishes to be notified about
email you receive from it" prompt.

But then you'd be able to do all sorts of clever stuff, including streamlining
email validation checks and password resets.

Everybody has email. You could create a "Login with Email" function really
easily on your website, and it would work for even more users than the "Login
with Facebook" option.

~~~
kodfodrasz
why should the browsers speak every protocol?

Why should everything be done through the browsers, instead of better
specialized programs?

Why should protocols designed for one problem be abused to solve other
problems?

Why not use client certs instead?

~~~
mike-cardwell
"Why should the browsers speak every protocol?"

Why should browsers only speak HTTP? Who made that rule?

"Why should everything be done through the browsers, instead of better
specialized programs?"

I never said "everything". "Better specialised programs"? What are you talking
about? I'm talking about essentially being able to access email from a
webpage. There is no "better specialised program" for doing that. I'm not
talking about webmail. I'm talking about automated emails.

"Why should protocols designed for one problem be abused to solve other
problems?"

What you call "abuse", I call "use".

"Why not use client certs instead?"

This has nothing to do with anything I've mentioned.

~~~
kodfodrasz
No better program to access email from anywhere than a browser. Have you heard
about MUA-s?

Special mails should be used for authentication which would specially handled
by the browser accessing your mailbox. This is abusing the mail protocols in
my opinion.

Certificate based auth does have something to with this: an existing,
partially supported solution for auth with no magic needed and no need to
reinvent the wheel, with hacks and extra complications.

~~~
mike-cardwell
"No better program to access email from anywhere than a browser. Have you
heard about MUA-s?"

You understand the difference between accessing email and reading email? I'm
talking about JavaScript accessing email, and acting on it. You're talking
about a human being reading a message.

"Special mails should be used for authentication which would specially handled
by the browser accessing your mailbox. This is abusing the mail protocols in
my opinion."

We're already sending registration emails and password reset links. We
currently have a system where the end user has to read an email and click a
link in it. My suggestion would just allow us to skip the human part and let
the JavaScript read it directly, _with_ a perfect fallback built in for people
who don't have their browsers configured to have access to their mail.

"Certificate based auth does have something to with this: an existing,
partially supported solution for auth with no magic needed and no need to
reinvent the wheel, with hacks and extra complications."

Even with certificate based auth, you'd still end up having email involved
with registration or password resets in some fashion.

~~~
kodfodrasz
You know, there is one thing I don't ever want to happen: to have JS running
in my browser access to my emails and act upon that automatically.

This has way too many security implications which don't make it a reasonable
idea:

1\. If sites can set up such action, then for that (I don't trust anybody's
site to have any form of Access to my emails, except my mail providers per
se),

2\. if the browsers supply these actions, then for that cause (it would be
exploited, or if it would be perfectly secure then it would also be perfectly
useless).

~~~
mike-cardwell
What security implications are there for a tab with the example.com origin to
be able to read emails that you receive from an example.com email address? If
it's behind a user access prompt, and the API requires that you specify the
sender and recipient to monitor for? E.g:

    
    
      navigator.notifyOnEmail({
        from: 'sender',
        to:   'recipientaddress',
      }, (email) => {
        /**
         * This callback is run whenever a new email
         * arrives from sender to recipientaddress.
         * Assuming the browser has access to the
         * recipientaddress account via IMAP, and
         * assuming the sender address matches the
         * browser origin and the user has given the
         * origin permission to do this.
         */
      });

~~~
DanBC
> that you receive from an example.com email address?

How do you know that it really was from that email address?

~~~
mike-cardwell
Why do you think that matters? The sending site knows if it sent an email. The
only thing it doesn't know is if you received it.

For an account registration or password reset email, the sending site will
typically send you an email with a link inside it containing a secret token.
If the JavaScript reads that it received an email with one of those links in
it, it will post that information back to the server so the server can
complete the function it started (account registration or password reset).
Obviously, at that point, it will know if the token it was passed was the one
it sent.

[edit] Also, as this system is being implemented from scratch, it could easily
be decided that emails which don't pass DMARC for example will simply be
ignored. Although I argue that is not necessary.

------
anoctopus
>Claim: With this setup, I can’t login easily with my LastPass, 1Password, etc
browser extension. >Rebuttal: This is a legitimate claim but it’s equally
plausible to use an email integrated browser extension.

You could do that, but since this isn't a very common login scheme, these
might not exist/be popular yet. Also, some of us use password managers that
aren't browser integrated, and that further reduces the chance of me having a
decent workflow for logging in to the site.

------
Sir_Substance
I'm glad to see this idea gaining traction. Passwords are a lazy solution that
is often not needed. This type of login is ideal for websites and services
that I might use less than 4 times a year.

I usually log into such services by doing a password reset every time I visit
their service, and this technique at least removes the risk of password
leaking.

------
shimon_e
This is commonly referred to as OTP and I have implemented it on a few recent
projects. It is very common in Asian countries.

------
jlebrech
also [https://passwordless.net/](https://passwordless.net/)

------
kodfodrasz
> Strawperson argument

Will this newspeak fury ever stop?

------
sareiodata
For WordPress:

[https://wordpress.org/plugins/passwordless-
login/](https://wordpress.org/plugins/passwordless-login/)

~~~
subkamran
Just what Wordpress needs.

------
zer0tonin
>Con: If database is compromised and passwords are reused across sites, then
attackers might be able to access more sites

Never heard of hashing or TLS/SRP?

~~~
manigandham
Those alone are not enough, a compromised database storing hashed passwords
behind a service that uses TLS would still allow the attackers to try common
passwords and hashing algorithms to see what passwords were used.

Password simplicity and reuse (especially across lots of people) is a major
problem with password security in data breaches.

------
_pmf_
So, nothing new since Kerberos?

