
It Is Time for Passwordless Login (2015) - atomical
https://medium.com/why-not/it-is-past-time-for-passwordless-login-4f468b812301#.jpknh88r2
======
bendykstra
There is another passwordless system called SQRL which is automated and more
secure. From the user's perspective, they scan a QR code or click a browser
extension and are signed into the site. Behind the scenes, a cryptographic
challenge (a response URL + nonce) is presented to the user's phone or browser
extension. The client signs the challenge using a per-site private key and
sends the result to the provided URL.

[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

~~~
Natanael_L
Tiqr predates it and does the same thing. However, U2F and UAF from FIDO
alliance are the new protocols that are being standardized, and they're
looking good too.

It is even designed to inherently resist tracking across services by using
unique keypairs per service in a clever way. No device identifier is ever
shared.

~~~
ronancremin
According to Steve Gibson (SQRL's inventor) tiQr is quite different:

"It superficially appears to offer a user experience similar to SQRL. However,
as is every other such system, what's going on is actually far more complex
and involves/requires establishing “shared secret” account credentials with
the authenticating website. As they explain on their technical page, TiQr is
based on the OATH (open authentication) OCRA protocol suite, which was
standardized by RFC6287."

[https://www.grc.com/sqrl/other.htm](https://www.grc.com/sqrl/other.htm)

------
stanmancan
I like the idea, but doesn't it come with a few security concerns? One blaring
issue is that email is sent in plain text, so anyone can intercept it and log
in as you.

I was originally going to complain that anyone who has access to your email
now has access to all of your accounts, but upon further thought I don't know
how much of a concern this really. First, the vast majority of people use the
same password everywhere anyways. Second, most services use your email to
reset your password anyways. The only security difference I can think of is if
someone uses your email for a password reset and changes your password, it
becomes very obvious there might have been a security issue when you try to
log in and your password doesn't work. If all someone has to do is follow the
link, there's nothing to create that suspicion.

A few other things to consider: \- How long does the token emailed to you last
for?

\- If I send a new token, do previous sessions expire? \---- If so, how can I
be logged in via multiple browsers/computers? \---- If not, does an attacker
have permanent access to my account if they got access to a single link?

~~~
joeyh
When I implemented this, I made the following choices:

1 hour login email expire time by default, tunable. I'd make it shorter, but
it has to get around greylisting.

Sending a login mail and logging in does not affect existing browser sessions.

Only allow a login email to be used one time.

Only allow the last login email sent to be used, not old ones. This and the
expiry keep email archives from becoming a problem.

Another thing you could do is set a cookie and have the login link check for
the cookie. That makes the link worthless even if the attacker intercepts it.
But, it lets the attacker DOS a user and prevent them from logging in by
continually requesting new login emails, so you'd probably want to allow
previous login emails to be used.

Of course, as a user, how do I know which of these security tradeoffs a site
has chosen? It's as bad as using a password and hoping they don't store in
clear text. It would be better to have a protocol for login that makes clear
choices.

------
paulcole
I don't see any mention of how log out works. Is it as soon as the browser
window is closed? I'd find that a little annoying on my own device, but it
would be essential on a shared computer-- at the library for example.

I'm thinking a checkbox saying "Shared Computer" and issues a link with a
different session length (or logout on window close) if checked?

Personally I love this idea as managing passwords has become really unwieldy
and I don't trust any password manager service. Plus for a few sites that
require really bizarre password length/character requirements/etc., I just
reset them overtime I want to log in anyway.

~~~
josephorjoe
I don't think this pattern requires a change to how log out works. It's just a
change to creating a session and shouldn't impact ending one.

I'm definitely in favor of making people create fewer passwords. It's a
nuisance that probably has a net negative affect on security by encouraging
people to re-use weak passwords.

~~~
criddell
I wonder how many public computers are configured to end sessions when the
browser is closed? Actually, can you even configure that anymore?

~~~
WorldMaker
Incognito Mode, In Private Mode, whatever you want to call it. Browsers now
give you a spiffy, hard to miss logo when in such a mode these days now too.

~~~
criddell
Oh right. I wonder if libraries could configure their computers to always be
in private or incognito mode?

~~~
WorldMaker
Chrome supports an incognito command line switch you can embed into
shortcuts/launchers:

[http://www.tekrevue.com/tip/incognito-mode-
shortcut/](http://www.tekrevue.com/tip/incognito-mode-shortcut/)

Firefox similarly offers a -private flag:

[https://developer.mozilla.org/en-
US/docs/Mozilla/Command_Lin...](https://developer.mozilla.org/en-
US/docs/Mozilla/Command_Line_Options)

Edge does not currently support the same, but there's a UserVoice request on
the topic:

[https://wpdev.uservoice.com/forums/257854-microsoft-edge-
dev...](https://wpdev.uservoice.com/forums/257854-microsoft-edge-
developer/suggestions/9245247-inprivate-command-line-switch)

------
d0lph
This seems to make urls themselves passwords, and your email a password safe.

~~~
WorldMaker
These are one-time use tokens, just like you should use for a "Forgot Your
Password" email login. It's literally the same steps, just there's no new
password to input, the website just gives you a login cookie and you can go
about your day.

~~~
mattashii
The point is that the most commonly used e-mail protocols do not have safety
built in. The solutions for this problem (e.g. PGP signing) are not adapted
widely enough to be considered adapted by the market.

If you'd want to use two-factor authentication by verifying access to the
mailbox, you have to make sure that that (the connection to) the mail box is
safe as well, which can potentially be very hard.

The mailbox still is a safe, but only from the moment that the mail has been
sent to the moment the page has been requested. Mind that a safe connection to
your mailbox does not also mean a safe connection to the server, but that is
something that is covered by https+certificates (mostly).

~~~
WorldMaker
This is no worse a security footprint than the existing, requisite "Forgot
Your Password" flow. It's the exact same security footprint.

TLS is already an under-spoken requisite of SMTP communications from any
webserver doing "Forgot Your Password" workflows. TLS between mail servers is
also already a de facto SMTP requirement for most bare minimum spam fighting
mechanisms.

~~~
mgreg
True that the password reset and the "login" using this proposal travel the
same path and present the same attack vector but there is some disadvantage to
the frequency in which the "login" system would travel down this less-than-
secure path. The more times you use this the more likely that someone will
just happen to be watching and waiting at the right time.

Let's not forget that most of the email system is still not encrypted (last
time I checked anyway) even though the last mile between your mail server and
your client may be.

~~~
WorldMaker
Frequency is also essentially the same: you can request a new login token
equally as often as you can request a new "Forgot Your Password" token in that
they are both manually requested with only an email address.

There are also already a growing number of users that use "Forgot Your
Password"-only login (most accidentally; human memory is porous) day to day.

Which is not to say that we shouldn't make email better and more secure, but
that the security of our email infrastructure is a red herring of sorts in the
larger security discussions of "passwordless" login, given that we are
_already_ equally insecure in every website that has a "Forgot Your Password"
button that accepts anyone's email address.

------
fosco
This is inherently a password in the form of a url similar to using REST which
still requires a password to obtain the link in the first place (email) I only
see this as a partial solution.

~~~
eximius
All non-PK cryptography eventually boils down to a 'password' if you call it
that.

But this isn't a password, it's a shared secret. Which IS a good solution (not
GREAT, but better), it just shifts the problem into communicating the shared
secret. This is where TOTP comes in for most 2FA implementations. This
particular scheme just uses email.

------
joeyh
This is clearly a Worse is Better solution. Where the "worse" is the
complicated and often not user-visible process involved in getting the login
email to them in a timely manner.

That said, I implemented it a while ago, since there's no widely deployed
distributed alternative, and as seen with OpenID, attempts to create one will
be frustrated by entrenched interests and technical debt.

I still think that Mozilla could have gotten around that problem with Persona
if they had built it right into the browser. Pity.

~~~
WorldMaker
It's more "Less is Better"; today for a password login system you need to have
and secure:

1\. Password database 2\. Password UX 3\. Forgot Your Password UX 4\. Forgot
Your Password one-time-use token via email/SMS

This drops 1 and 2, leaving 3 and 4 as the remaining security footprint.

(I also think that Persona was heading in the right direction and wish it had
received better traction.)

------
digitalengineer
WordPress has CLEF. Any thoughts?
[https://nl.wordpress.org/plugins/wpclef/](https://nl.wordpress.org/plugins/wpclef/)

~~~
throwaway2016a
Clef works for way more than just Wordpress.

------
elbigbad
So does this mean one has to go into their email everytime they need to log
in, or just until the cookie expires? I assume it's the latter.

It's a little more inconvenient in the second instance that traditional
password entry (given that all my passwords are saved in Chrome), but sounds a
lot more secure. Especially since I use a hard gmail password and two factor
authentication to access email.

Would be nice to add a 'log out on all machines' link to the email with the
password button as well.

~~~
WorldMaker
Just until a session cookie expires. Session management can/should be much the
same as you would expect.

The benefit here for you, though, is that you get "free two factor" on these
sorts of sites, without those sites having to implement it, simply because you
use a two factor email. It's a rising security tide, of a sort.

------
sareiodata
For WordPress I developed this simple plugin based on the initial article

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

[http://www.cozmoslabs.com/31550-wordpress-passwordless-
login...](http://www.cozmoslabs.com/31550-wordpress-passwordless-login/)

------
umut
It would be cool if someone does an A/B testing over a significantly big
population of users and show us the dropoffs on each version. I would love to
have no password login (temp token), but if the users don't receive them on
time (email deliverability might be laggy at times), or they don't get the
idea, or they don't care/like the method.. Well, you got my point.

------
jessaustin
I wrote a Koa middleware that I've found handy for this:

[https://www.npmjs.com/package/koa-signed-
url](https://www.npmjs.com/package/koa-signed-url)

It introduces the idea of a "signed URL", which can be verified or rejected
based on checking a signature query parameter. You can send such a signed URL
via email, text message, etc.

------
madbiz
Any reasons why this cant be done using push messages?

Another way could be to send an intent to the right app using some special
email header (X-App-Scheme) by the mail app.

The current email login flows force the user to open the mail app and to click
the link inside the mail (which then normally opens the app using a registered
scheme).

~~~
mderazon
Paswordless login actually fits even nicer in mobile. You can make the email
link open as a deep link in the app and continue right where you left. Context
switching in the app is minimal and in mobile apps sessions are usually more
persistent anyway

See [http://www.drzon.net/passwordless-login-in-mobile-
apps/](http://www.drzon.net/passwordless-login-in-mobile-apps/) for what I
mean

~~~
madbiz
I described the way it is currently done on mobile devices but i was thinking
about a way to even cut that context switch by letting an app react to an
email rather than handling the link scheme.

------
shanecleveland
[http://searchpath.io](http://searchpath.io) does this nicely.

------
d0lph
Another concern, this is going to be saved to the browser's history, and thus
to the HDD.

~~~
WorldMaker
These tokens should not be able to be reused, even if found in browser
history. Additionally, the HTTP flow is to 301 redirect to the user's homepage
or dashboard and browsers tend not to bother storing URLs that result in 301
redirects.

------
Zooper
PGP Keyring as part of native Web Storage or bust.

------
vacri
Great, so now instead of a password to remember, I have to remember a link?
How is that substantially different from carrying around emails with passwords
in them? Or with dynamic links, I now have to go through a separate
application with an extra click-link-to-login-then-close-tab-and-find-
original-tab motion?

Instead of logging in by opening a password safe, I now have to log in by
opening email... and have a new source of email clutter... and _can 't share
an account_ with other people... and disposable emails for signing up to less
reputable services becomes less of an option.

And what happens when you move email addresses? Or there's a problem with
email (delays are common)? A password safe that relies on an asynchronous
messaging protocol? Yuck.

~~~
gknoy
I like Steam's solution:

    
    
        Login on new machine  (Email + password)
        They send me an email with a short code (~6 characters)
        I copy/paste those few characters
        They remember that machine for ${a-long-time}

