
Passwordless Products - stanleydrew
https://blog.bolt.co/2014/01/28/passwordless-products.html
======
tptacek
This idea is approximately as old as webmail.

It doesn't fare well in the real world for two reasons:

1\. It is tremendously inconvenient for normal users, who do not find it
simple to flip to their "secure channel" to recover their "token" (or, for
that matter, have any freaking idea what a "token" delivered over mail
actually means). Even when the concept is implemented "transparently" \---
"log in via Facebook" or "log in via Google Mail" \--- people still hate it.

2\. It assumes that the small subset of users who care about this problem are
comfortable having all their security rest on their email account. That's not
necessarily true. For instance, a decent-sized chunk of the power-users who
care about password security already use password managers like 1Password,
which this idea is not trivially compatible with.

Services that actually care about security (a) store authenticators in ways
that aren't easily recoverable in the event of a breach, and (b) offer two-
factor authentication, which is superior to "go fetch this login token over
email".

~~~
dpcan
But it could.

What if the website I wanted to login to sent me a text with the token? Then
all I had to do was reply to the text with a Y or N to log me in (or enter the
code directly into the site if I wanted to).

When the text back is received by the host, my browser finishes the login
request.

If you can sync your texts with your PC, maybe it could all be done right on
the same screen where you are trying to login.

I think this could be mainstream. The hurdles don't seem that huge, and you
can still leave passwords in place for a while until everyone is on board.

~~~
arnarbi
This is already mainstream. Facebook even pulls the code directly from your
SMS if you are logging into their Android app.

It's just that it's a second factor to the password. Your phone can be stolen
as well (although such theft is harder to scale) - so keeping the knowledge-
test around is important.

I agree though, if you don't care about security, OTPs are potentially much
more convenient than traditional passwords.

------
jader201
These sites/articles that try to solve authentication by getting rid of
passwords seem to keep forgetting something -- you still need a
password/authentication to something else.

If I sign on w/ Facebook/Google, _they_ still have to authenticate me with a
password.

If I have a token emailed to me, I still have to access my email with a
password.

If I have a token sent to me via text, I may still have to unlock my phone
with a password -- and I have to have the phone on me.

There are only three ways, that I can think of, to authenticate someone:

1) a password (or some other secret)

2) a token stored as a cookie or some other file on your computer/device

3) a token sent to/stored on a personal device.

Most products already implement #1 and #2. They will look for a token, and if
not present, will prompt for a password. In the case of third-party
authentication (Facebook/Google/email), _this_ authentication is still done
via a token, and if not present, will prompt for password -- it's basically
pass-through authentication. I don't think anything can be done to
revolutionize either of these.

That really only leaves us with #3. Texting a token to a phone works and
prevents having to remember a password (or use an unsafe password), but it's
still inconvenient.

Has someone tried creating another device that serves as a "key" and connects
to your device via USB/bluetooth that can be used for authentication purposes?

This is about the only thing I can think of that would be a step in the right
direction, but even then, there are probably still a handful of reasons why
that would be problematic.

~~~
stanleydrew
"Has someone tried creating another device that serves as a "key" and connects
to your device via USB/bluetooth that can be used for authentication
purposes?"

As far as I know many banks outside the US issue a key fob which generates
tokens. Those are essentially equivalent to something like the Google
Authenticator app.

~~~
jader201
Right, but even key fobs are no better than sending a token to your phone.

If this was to really get adopted -- by both the issuer and the user -- it
would have to be easy. A bluetooth device would be ideal, as it would allow
wireless communication to the target device being authenticated. Stick it on
your keychain and forget about it.

------
rgbrgb
I think this is generally an improvement over the status quo but it doesn't
solve the problem we've created with email being our single point of security
failure. From where I stand, the only sane way forward is to stop storing data
in these big juicy silos that are very attractive targets for hackers (gmail).

~~~
gagege
What if each user had a personal data store, either running on a server they
pay for, or one that they host themselves, at home? All their blog posts,
comments, pictures, videos, location history, and everything else, is owned by
them. They just give sites permission to access (create, read, update, delete)
their data.

I'd love something like that, as a user. As a developer, it may make some
things harder or slower. I'd totally be willing to pay that price though, if
it meant never having to be responsible for thousands of user's data again.
The user becomes responsible for their own data.

~~~
stanleydrew
This is essentially what Google and Facebook, and to some extent even Apple,
are attempting to become: giant stores of user data that you auth against.

Also check out Mozilla's BrowserID if you're interested specifically in the
auth piece.

~~~
gagege
Yep, exactly. That's where I got the idea. I feel like, if someone's going
hold all of a user's data in one place, and be their online identity, in a
sense, it should be the user.

~~~
TylerE
Really? Users are clueless. Always have been, always will be. Give control to
the user and it'll end up sitting on a Windows shared drive on open wifi
because that's "easy".

~~~
gagege
People learned, over time, that they have to lock their doors and keep their
wallet safe. How is this different? Just make the learning curve as shallow as
possible.

~~~
bradbatt
It comes down to educating users in a way they understand. Part of the problem
is that they simply do not grasp the risks or the issues involved. The
problems are either too technical or confusing or they may simply not even
know that the issue exists.

When wireless routers first came out almost none of them defaulted to having
security. Unless you were fairly technical minded, you simply left the
defaults in place. Not because you were clueless, but because you trusted that
the manufacturer _must_ know what they are doing...and you certainly don't.

Now they all come with security enabled, plus, users have been educated as to
_why_ they should use it. They don't need to know how it works-just why it is
important and what it means _to them_.

Same thing goes for enabling HTTPS on websites, adding two-factor auth to your
email, having unique passwords on different sites, etc. Part of the
responsibility of users' cluelessness falls on us. We need to find better ways
to communicate to the average user, who has a minimal understanding of
technology, in a way that is meaningful to them.

------
spellboots
Mozilla Persona is basically this but better thought out. There is a good talk
about it here:
[https://www.youtube.com/watch?v=nJff23UdNAI](https://www.youtube.com/watch?v=nJff23UdNAI)

~~~
stanleydrew
The thought that's been put into Persona (formerly BrowserID) is excellent,
but as far as I can tell it is intended for use on websites. Perhaps it could
be made to work in a mobile app though?

~~~
spellboots
Yes: [https://github.com/mozilla/persona-
ios](https://github.com/mozilla/persona-ios)

------
pgrous
Take a look at Steve Gibson's SQRL system (pronounced “squirrel”) SQRL =
Secure Quick Reliable Login
[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

Illustrated guide here - [http://www.sqrl.pl](http://www.sqrl.pl)

------
danielzarick
I really love when I see products take this route. I'm also currently working
on something that is passwordless. I think there is a small cognitive hump
that new users have to get over, but I'm working on ways to make it smoother.
Nonetheless, I believe this route is the future & we will continue to see more
passwordless products, which will increase the general understanding of how to
use them.

------
simonhamp
We've been doing password-less entry for years over SSH with certificates. You
generate a key, share the public parts and do some magic with your private
parts (ahem) and it all works.

What I think the OP is looking for is a similar pattern for the web and
browsers. Is there no way we could use the FileAPI to check for a keyfile?

[http://caniuse.com/fileapi](http://caniuse.com/fileapi)

~~~
ryan-c
SSL/TLS client auth is an option, though the UI isn't great.

[http://en.wikipedia.org/wiki/SPKAC](http://en.wikipedia.org/wiki/SPKAC)

------
helipad
I've wanted to bite the bullet with this, but not enough of a security expert
to do it confidently. How does this stack up?

I like the idea of keeping someone logged in, then they can choose to log back
using whichever means they decided when creating their account - email, SMS,
authenticator app.

------
conorclearshot
My worry is not so much the front end attack or access, but the data on the
hosting servers being peeked at without a record of it, or any hacking
required.

------
ruddct
I recently built passwordless, email-based authentication into the iOS app I
develop ([http://varka.la](http://varka.la)). Still tweaking how it's
messaged, though, as folks seem to be a little confused about how it's
different than a normal registration flow one might see in another app.

------
d64f396930663ee
So if the token expires, how do you log back in? What happens if you want to
use a different browser? Or buy a new computer?

~~~
hundchenkatze
None of these would be an issue...

From the article your "password" is a:

    
    
         short-lived one-time-use tokens delivered over a secure channel that they control
    

So, your session times out, log in again by requesting a new one-time-use
token delivered over the channel of your choosing.

What to log in using a different browser, it's the same as before, get a new
token.

You get the idea...

~~~
d64f396930663ee
No, I don't get the idea. If I'm requesting a token for a certain user, how
can the server reliably determine if I actually am that user? If it just
authenticates every request, what's the point of even having a password?

~~~
d64f396930663ee
OK nevermind. I get it now, it's just emailing you a new token everytime you
want to use the site, or something like that. It's just such a terrible idea I
couldn't wrap my mind around it. Who would ever want to use a website like
this?

~~~
napoleond
That's kind of a stretch. There might be valid issues with the approach, but
it isn't as mind-numbingly terrible as you're suggesting. You'd just
authenticate new devices/browsers every time you needed to--you wouldn't be
doing it every time you used the site.

~~~
gagege
I like the idea of getting a text message on your phone with a very quickly
expiring key (60 seconds), or having an authentication app like Google's,
which works for a bunch of websites. I do admit, even that's kind of annoying.
That's why I started using a password manager.

------
omgitstom
The password isn't the problem. If PSN / Adobe / Etc used large random salt
for each password stored, industry approved hashing algorithms and other best
practices while storing passwords, there would have been less of an issue with
getting those hashes exposed.

~~~
redblacktree
But just as users don't generally pick secure passwords, lazy/time-
pressured/incompetent (pick one) developers don't create secure password
storage mechanisms. If the fix is as simple as defaulting to the _other_
factor of two-factor auth for single-factor auth, it's worth thinking about.

~~~
omgitstom
Definitely is worth thinking about. Defaulting to another factor would still
be an issue as well. There are a few discussions on this post that highlight
them.

------
gagege
Do phones send some kind of unique Bluetooth signature that could be used to
authenticate a user? The user would have to just tether their their phone to
the computer. A browser plugin would authenticate sites that way. That seems
like it'd be pretty painless.

------
Nate630
Sounds like we need an 'Internet'
[http://en.wikipedia.org/wiki/Kerberos_(protocol)](http://en.wikipedia.org/wiki/Kerberos_\(protocol\))

------
nathancahill
Have you heard of 2-factor authentication? Sounds pretty much like what you
described. Specifically, the way Duo Security implements SSH logins.

~~~
stanleydrew
2-factor auth is great. The suggestion is that if you are only going to
implement one factor, it should look more like the "traditional" second
factor. Basically we should flip two-factor author on its head. A user-defined
password should be the second factor, not the first as is currently assumed.

~~~
umeshunni
That's essentially a chip-and-pin like system, right?

------
lhgaghl
Waterken has solved phishing/authentication/CSRF/clickjacking all at once by
doing approximately nothing. It has existed for years.

waterken.sourceforge.net

See specifically:

[http://waterken.sourceforge.net/web-
key/](http://waterken.sourceforge.net/web-key/)

and

[http://waterken.sourceforge.net/clickjacking/](http://waterken.sourceforge.net/clickjacking/)

