
Passwordless authentication: Secure, simple, and fast to deploy - bpierre
https://hacks.mozilla.org/2014/10/passwordless-authentication-secure-simple-and-fast-to-deploy/
======
throwaway9724
At my company we've been using this technique for years. Users have always
hated it and after waiting a long time for people to come around, we are now
transitioning back to traditional login mechanisms.

The basic reasons users hated it was that a login mechanism needs to be
reliable. In particular, we make business software, so if the user was ever
unable to get into the system it was a big problem.

While it may seem that you "always" have access to your email, or sms. Not all
users (especially non-technical users) always have access to these things.
Meaning, even if they have access 98% of the time, that other 2% of the time
infuriates them.

It was also a usability nightmare among non-technical users. Traditional login
mechanisms dont necessarily mean a more usable experience, but its a pattern
that _everyone_ knows.

I think login mechanisms on the web can be improved, but not like this. As
someone who has a lot of experience with this, I strongly recommend against
it.

~~~
tracker1
This really affected me the one day in the past 3 years that I forgot my phone
in the morning... There was one site I had enabled 2FA (two factor
authentication) on that I hadn't logged in from work yet, and it was really a
pain not being able to access it.

Honestly, I've been pretty happy simply using LastPass (with a really long
passphrase that I haven't shared with anyone) and generating more complex
passwords for sites...

Just the same, not sure what the best answer is... Especially considering
shared computers, portable devices and other devices which may get stolen or
hacked.

~~~
squeaky-clean
I've been very happy with LastPass too. I use it on my desktop and pay for the
mobile app. But what I don't get is why we still need to use a password
manager extension/app. Why isn't it built into the browser yet?

Google already has all of my passwords saved, and synchronized online across
devices for whenever I use chrome (well, the passwords I used before switching
to LastPass). Why can't it automatically generate secure passwords for me just
like LastPass does?

~~~
sneak
Why can't we be using client certificates generated and stored and synced this
same way instead of passwords?! Imagine a world without cookies...

~~~
rjaco31
Because that would mean you could only log in with computers storing your
cert. Passwords might have lots of drawbacks, but it allows you to log in from
anywhere on any computer without any other requirements beside remembering it.
I don't see this property in any of the proposed solutions to replace
passwords thus far.

~~~
illumen
You remember one password... and then can access your master password list.

~~~
rjaco31
And where is stored this master password then? If it's on your
browser/computer, it's not portable. If it's online, it's possibly less secure
(especially if you're not the one hosting it). A physical token might work,
but it's usually too specific and not scalable.

Nothing beats plain old password as convenience, that's why they are still so
wildly used despite lousy security properties.

------
wiremine
While this feels similar to a password reset process, it is different:

a. you're sending the auth credentials every single time a user wants to
login. If email was secure, that might be fine, but it's not.

b. On a password reset, you typically require a user to actually reset their
credentials, and then allow them to continue. In this case, if someone
accidentally forwards the email, or enters the wrong email address, the
recipient automatically gets access to the account, no questions asked.

It is an interesting concept, though. I don't really know if I like it yet,
but it's nice to see people trying to work on this problem.

~~~
dbla
Account recovery emails should probably use one time tokens, meaning that
after you click on the link once, the link becomes invalidated. This would
largely solve the issue with point b.

~~~
PythonicAlpha
Not only one time tokens, but with limited life-span. So after a while the
token expires and is useless. This is a must for such a scheme.

~~~
sturadnidge
Both of these, plus a differentiator between 'current' and 'new' token
requests - without that, it's an easy way to log people out of sites by simply
knowing their email address. To the point about not always having access to
email, it's a pretty simple denial of service vector.

~~~
PythonicAlpha
Can you clarify, what you mean by "differentiator between current and new
token requests"? Currently I don't exactly know which attack form you mean and
how it could be prevented by such a "differentiator".

(an example would be nice)

------
marco1
The very website they link to [1] via its HN thread [2] states correctly that:

"No, email is not a secure medium. It was never designed to be one. It’s
susceptible to Man In The Middle (MITM) attacks and a slew of other issues.
Users might also have their email accounts abused or hacked into (how many
people do you know who have left their GMail logged in on a public computer?).
And what about if their email provider gets hacked or their backups stolen?"

Mozilla should know that email is not an adequate medium for one-time password
delivery.

They are replacing strong authentication (2 factors) with its second factor
alone.

[1]
[http://plaintextoffenders.com/faq/devs](http://plaintextoffenders.com/faq/devs)
[2]
[https://news.ycombinator.com/item?id=7943365](https://news.ycombinator.com/item?id=7943365)

~~~
okbutnormally
> They are replacing strong authentication (2 factors) with its second factor
> alone.

Are they? They don't mention anything about replacing 2 factor here.

A typical login is compromised if you know the password _or_ if the email is
compromised. This is _not_ increasing the attack surface.

~~~
andrewstuart2
One problem is that SMTP itself [1] is just a plaintext email format. Sure,
you can send it over a secure connection and most do, but that's left
completely up to the provider to decide and therefore never guaranteed.

[1]
[https://www.ietf.org/rfc/rfc0821.txt](https://www.ietf.org/rfc/rfc0821.txt)

~~~
Fuxy
This is by no means a very secure option but do you really care if your
www.anime-planet.com or konachan.com account don't use 2 factor
authentication.

Some websites just don't need such a high level of security plus you could
argue they are probably less careful with your password than say Google is
with your email.

Now it can still be hacked but you could argue this is probably an increase in
security although it does create a central point of failure just like password
managers.

Nobody says Google or Amazon should start using this but websites with a lower
requirement of security shouldn't inconvenience their users unnecessarily.

If you're only need is to identify the user for something banal that couldn't
do much damage if it gets hacked then this is a good solution.

------
steakejjs
FD I work for a password manager...but I would still think password managers
are better even if I didn't.

1) Password managers have security qualities built into them, example forced
logoff after X amount of time. Someone who leaves their email up is still
leaving themselves available for an account theft. The password requires a key
to decrpyt. This isn't the case for email 2) Email is not meant to be secure
and attempts to do so have gone pretty badly. A lot of the big email providers
are leaps and bounds ahead of where they were 5 years ago but email as a whole
is still broken.

I think this is really cool and has a lot of potential, but these things still
need some work. You probably shouldn't be rolling this out on things that
require a high level of security.

~~~
jberryman
1 seems completely orthogonal to the issue of authentication, and I'm not sure
what you mean by 2; basically every site on the internet is built on the
premise that your email is secure, and again I don't see how password managers
are relevant here.

~~~
steakejjs
Password managers are a better solution to prevent people from memorizing a
lot of passowrds....Copied straight from the article "there is no risk of
users reusing passwords"......That is what they have to do with this
conversation.

1) isn't completely orthogonal to authentication. Good security products need
to help you maintain good OpSec. Pretty much all password managers have
features that try to help users maintain good OpSec and cut down on the
mistakes they can make.

------
harshreality
The FIDO alliance has a working solution to the annoyance of the 2nd factor.
It requires mobile device support or a hardware token (Yubikey Neo as of
October supports the FIDO protocol), but it's much better than standard
existing 2-factor because it doesn't require typing in a code from a dongle or
app. Instead, the app or dongle authenticates directly once user presence (or
in some cases, depending on the dongle or app, biometrics) are confirmed.

That means, for low-security applications, users can reuse passwords, or not
have passwords, using only this second one-time-password factor, as long as
they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery
protocols are at the discretion of different services, but a recovery code
that you keep in a secure location is one way way to do it, or emails or text
messages for less secure applications).

For high security applications, it avoids the annoying scrolling through a
list of 2-factor accounts to get the right code, then typing it in manually.

 _Email_ or _text message_ , even if secure (text messages are not, and emails
are probably not) _require internet access_. Mobile internet access isn't
always available when logging into a service from some other device that has a
different internet connection. Similarly, the mobile network (for text
messages) is not always available, either. Even if it's done through email,
email service might be down; the machine used to login could be compromised so
you wouldn't want to input your (hopefully very secure) email password on the
same machine you're using to access some other service. If you don't have
internet access via a separate more trusted device, the rationale for having 2
factor is weakened.

A good presentation on FIDO is here: [http://www.yubico.com/2014/07/future-
online-authentication/](http://www.yubico.com/2014/07/future-online-
authentication/)

There's nothing preventing a FIDO-enabled service from also using email or
text message for users that don't have FIDO devices, and account recovery can
be done via recovery code, text, email, backup FIDO device, phone call, or a
combination. It's all up to the service.

~~~
peterwwillis
Sorry, I don't watch hour-long presentations when all I want is a bullet list
of features and requirements. So I have no idea how FIDO actually works.

Here's what I will say: the best combination of security and usability would
come in the form of an app that bridges an automatic communication (such as
from an SMS, e-mail, or existing [https?] connection) to a TOTP token provider
(either in software or hardware) and a prompt to the user to submit the token
_over a secured connection_ to the requesting provider. For internet-less use,
you'd simply generate and copy the token the way Google Authenticator works
now.

From the looks of the NEO & U2F yubico page, it sounds like this is similar to
what they're going for; is that correct?

~~~
harshreality
It uses asymmetric crypto. It generates a unique keypair for each service you
register with, each key linked to a specific dns or service domain. It uses
USB or NFC (and requires app, i.e. browser, support) rather than displaying a
code and having the user type it in somewhere. The app or hardware key
confirms user intent (by requiring a button-press or sampling biometrics), so
for example a plugged-in NEO won't auto-authenticate to a site. Beyond that,
it works pretty much how you'd expect.

Adding FIDO 2-factor to a service, when the browser/app stack supports FIDO,
is as simple as adding a prompt and button press on the NEO to the process
(either account setup, adding 2nd factor, or during login, it makes no
difference). All the details of creating a keypair or authenticating to a
service using a key associated with that service are under the hood.

There's nothing preventing FIDO devices from having additional requirements.
They could require a PIN. They could require biometrics. They don't have to be
a separate minimal hardware dongle (although, obviously, for the best
security, you'd want them to be). (The S5 Paypal + FIDO demo uses the phone
itself as a FIDO device, and a fingerprint swipe.)

~~~
peterwwillis
Cool. So it is similar to what I describe, with perhaps one or two
differences. For example, you say it requires app support, so.... if you're
logging in through your desktop, does your desktop app need to support it? Or
can your mobile handle the authentication independent of your desktop?

The reason I ask is that requiring one device to complete the authentication
is less secure than two independent devices. While it's great that the NEO can
plug into your desktop to auth with the browser, or that NEO plugs into your
mobile to auth a mobile app, what I actually want is to start authentication
on the desktop and finish it on the mobile, independently.

~~~
harshreality
I don't know if that's possible with the protocol.

I guess it would require associating a key with a kind of authentication API
endpoint for that service, stored on the device, and forcing the service
provider to maintain that authentication API url indefinitely (or would have
to force regenerating 2-factor keys when the auth endpoint changes).

It would also require that your FIDO authentication device has separate
internet access (either itself or by proximity/connection to a smartphone).
That's unreliable, and one of the reasons I hate it when routine
authentication tokens have to be sent from the service over data links. It
also takes additional effort to pick up your phone, unlock it, get to a FIDO
middleware app, select the site you're authenticating to, and then completing
the authentication. I don't even know if that's possible... it would require a
device (computer or smartphone) to be able to enumerate accounts stored on,
for example, a FIDO hardware token. That "feature" could be bad. It would also
have to violate the (typical?) FIDO protocol where a hardware token is
responding to a specific authentication challenge. Sending authentication
authorization blind, which would be required if it were sent out-of-band from
a different device, breaks the continuous thread of login attempt, then
challenge, then response, then mark the user logged in [and set a browser
cookie]. The separate device authenticating out of band can't know that there
was even a login attempt. It could be sending authentication tokens
continuously, only restricted by service-side rate limits.

> requiring one device to complete the authentication is less secure than two
> independent devices

What security vulnerability is there with using the same internet-connected
device to authenticate with the FIDO 2nd factor, that can't also be done by
malware waiting until after authentication and hijacking or doing malicious
things with the account then? Is your concern about malware on the computer
compromising the hardware token? Malware on a smartphone could compromise a
hardware token too, in that case.

I think there's a much bigger problem: FIDO implementations that don't have a
separate hardware dongle; for example, using a Samsung S5 to log into some
service, and using a FIDO-enabled app that stores credentials in normal
private app storage space on the S5 itself. A secure computing enclave (like
on Apple phones, does the S5 or any android have that) makes that marginally
acceptable, but far from ideal.

~~~
peterwwillis
This actually makes malware less of an issue, because you'd need to target
both a desktop and a mobile device of a particular user in order to MITM. The
only things that are happening 'automatically' is the request being sent to
the user's mobile device, and the entire process can be verified
cryptographically to ensure an attacker doesn't send a false request.

    
    
      (HTTPS)
      Client -> Server: LOG ME IN PLEASE
      Server -> Client: Do you have a cookie?
      Client -> Server: NO, BUT HERE's MY PASSWORD
      Server -> Client: I've just sent you a request for an additional auth token. Please confirm it to log in. And please stop shouting.
    
      (Email, SMS, HTTPS)
      Server -> Client's Mobile Device: Here's a token. Sign it with some crap you've already got and give it back to me.
    
      CMD generates new token after confirming origin of original request; uses software, or talks to hardware token.
    
      (App, Website)
      CMD -> User: IS THIS REQUEST OKAY? CAN I SEND THIS THING?
      User -> CMD: Yeah sure, I requested this login. *pushes button*
    
      (HTTPS)
      CMD -> Server: HERE'S YOUR NEW SIGNED TOKEN
      Server -> CMD: Thanks. Here's a cookie to remember me by.
    
      Server -> Client: Page refresh! We got the right token from your mobile device, so here's your new cookie, you're logged in.
    

The only major security pitfalls here are in how you deliver either an app or
a website to a user remotely, but there's plenty of good ways to do that
already. You can even use boring old existing PKI.

You're not sending authorization "blind", though. You have to request the
login from one device with a password, and approve it from another with a
button push. In this way, only logins that _you_ requested get sent to you,
and only requests _you_ approve get sent back, and _both devices_ would have
to be hacked by an attacker to intercept either part of the authentication
process. Well, unless they both have your cracked password and inject malware
on your mobile. Perhaps putting the button-pressy part on the hardware keyfob
is safer :)

Even if none of this were cryptographically signed, look at the typical
2-factor SMS with this process. A user attempts a login and a text is sent to
them with a code. The user then puts this code back into the login screen and
presses return. If they could simply press a button on their phone they could
approve the login without having to type the code in. Of course, we want to
require a button press, because an automatic login means anyone who initiates
the login (like an attacker with a stolen password) could log in
automatically. And what i'm proposing is basically this, but with actual
secure connections instead of SMSes or e-mails, and the ability to confirm on
the device that the request was legit and not part of an elaborate phishing
expedition.

All of this would work without a data connection because you could use QR
codes to enter the challenge token into the device and it would spit out the
response in a variety of formats.

~~~
harshreality
I don't think FIDO conflicts with what you want to do. It simply doesn't
mandate it.

If you wanted a 2nd channel confirmation like that, I suppose you could set up
the service to link a mobile device (there might even eventually be some FIDO
app that accepts FIDO challenge push notifications in a way that's not
service-specific). Then FIDO would be used exclusively on the second channel
(parenthentical stages 2, 3, 4 in your example). The web interface in that
kind of setup would have nothing to do with FIDO.

I don't understand the MITM malware threat model you're envisioning that can
hijack an in-band public key crypto exchange, but that can't simply hijack the
session on the browser after you've completed (validly) the out of band
verification.

Some of the complexity of FIDO is there to enable reasonably secure single-
channel authentication (as might be expected, there are trade-offs between
easy SSO and subdomain/origin policy security). But I think FIDO would still
be valuable if you wanted to do out of band confirmation without a browser.
The hardware dongles are standardized (although the requirements to unlock a
key can vary from a button press like on the NEO to, hypothetically,
biometrics in advanced dongles). Mobile apps would also be standardized, much
like TOTP is now, so you could use any FIDO app with any FIDO dongle (or no
dongle, if an app offers less secure on-phone secret storage). Without a
hardware standard, you either _have to_ store secrets on the mobile device, or
you run into the existing problem of needing N hardware dongles for N
services.

------
Xeoncross
The main problem I have with this approach is a theoretical one: What if I
can't get a cell phone or permanent email address?

You have to pay to have a phone and possibly have approval from the
network/government to join.

Email is a lot better since it's a totally open network. However, Even then
I'm leaving myself open to MITM attacks, being locked out of my email by
government orders, ISP complaints, company lawsuits.

I will never be locked out of my passphrase.

With that said, after almost creating swiftlogin to do this very thing, I
would support this effort as long as this does not become the one true way.

------
tylerg
Kudos to Mozilla for trying a new way to simplify passwords. Very similar to
something we implemented at Shop It To Me in June and that appeared in Hacker
News. Here's the link with the conversation:
[https://news.ycombinator.com/item?id=7818584](https://news.ycombinator.com/item?id=7818584)

And here's the announcement. [http://blog.shopittome.com/2014/05/29/bye-bye-
passwords/](http://blog.shopittome.com/2014/05/29/bye-bye-passwords/)

Overall it has worked very well for us and is no less secure in my opinion
than all the reset password options. 2-factor authentication is still better
though and should be used for the sites requiring the most security.

~~~
thesumofall
It's not a Mozilla solution, though, says the developer :-) Hacks is simply
publishing about it

------
scrollaway
I really believe in Persona. This is an interesting evolution of it.

Any Passwordless dev around? Care to shime in on this?

Edit: To be more specific, "token-based auth" is an interesting take on the
browser-based auth concept. I still think the latter is what will eventually
be the solution to the growing auth needs of the web: Authenticate to your
browser and your browser authenticates to web apps for you. We see the same
thing happening on mobile with apps (eg. on Android, users log into their
google account on the android system itself).

~~~
AhtiK
Persona is no longer developed by Mozilla -- Persona team has been moved to
other Mozilla projects:
[http://identity.mozilla.com/post/78873831485/transitioning-p...](http://identity.mozilla.com/post/78873831485/transitioning-
persona-to-community-ownership)

~~~
callahad
Maintenance of Persona is funded (and staffed), new development is on a
volunteer basis. However, there has been some renewed interest in hacking on
the codebase (including some pretty significant cleanup). Our immediate goals
are separating out Persona's various components into discrete modules and
getting new contributor documentation into place.

If you're interested in diving in, join the dev-identity mailing list and drop
me a line: [https://lists.mozilla.org/listinfo/dev-
identity](https://lists.mozilla.org/listinfo/dev-identity)

~~~
scrollaway
Dan, what do you guys need help with? I've attempted joining you guys in the
past but the IRC channel was dead for three days and the dev-identity list
looks overrun with spam.

~~~
callahad
_> what do you guys need help with?_

I'll post some trailheads to dev-identity by Friday; we're just now rebooting
some coordinated development effort. Generally speaking, our greatest
challenge is an enormous amount of technical debt in the main Persona repo[0].
The cruft and complexity hinder maintenance, slow feature development, and
present a huge challenge for potential contributors.

We're specifically trying to tease apart the verifier, frontend, and backend
into independent components, but literally any contribution to reduce code
complexity / cruft would be welcome. Some ideas: audit / upgrade our node
dependencies, replace npm-lockdown with npm-shrinkwrap, try to get Persona
running locally and file documentation bugs about what did / didn't work, open
a random .js or .ejs file and see if you can make it less verbose or complex.
All would be useful contributions.

 _> the IRC channel was dead for three days and the dev-identity list looks
overrun with spam._

Right now our IRC coverage isn't great, but the mailing list should be better.
The spam is an unfortunate side-effect of Mozilla's weird NNTP/SMTP hybrid
lists -- certain incoming messages are somehow bypassing the filters set up in
Mailman. I'll look into it more tomorrow.

Otherwise, if you mention my nick on IRC or GitHub, I'll see it. :)

[0]:
[https://github.com/mozilla/persona/](https://github.com/mozilla/persona/)

------
xnull
Why not PAKE?

"The SRP protocol has a number of desirable properties: it allows a user to
authenticate themselves to a server, it is resistant to dictionary attacks
mounted by an eavesdropper, and it does not require a trusted third party. It
effectively conveys a zero-knowledge password proof from the user to the
server. In revision 6 of the protocol only one password can be guessed per
connection attempt. One of the interesting properties of the protocol is that
even if one or two of the cryptographic primitives it uses are attacked, it is
still secure. The SRP protocol has been revised several times, and is
currently at revision 6a."

You can salt/password manager/email retrieve on the client side however you
want to strengthen you passwords or escrow keys without needing to share state
with third party services at all. And they never get a copy of your creds. The
server side can easily rate limit guesses per account, report access times,
and/or require CAPTCHA challenges.

[https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)

------
INIT_6
I think a good middle ground would be to implement this idea into a password
manager. You have one strong password to unlock your manager. Sites that
support passwordless Would send it to the password manager. Otherwise use it
as normal. As long as the password manager is supported on all platforms I
think this would be the best solution. As for how it would communicate I
always prefer pull rather than push.

------
trvz
Is this the fourth or fifth try of Mozilla to replace passwords? Surely it
will work _this_ time…

Edit: …which makes it totally sensible to invest time building your site up
relying on this stuff.

~~~
mixedbit
I only hope that an intention of this project isn't to "smoothly" kill support
for Persona. From a PR perspective this could look nicely: we kill the project
that you depend on, but here is some quite inferior alternative that has zero
maintenance cost for us.

~~~
callahad
I don't believe that's at all the intention. However, I am quite interested in
this approach, and will be watching Webmaker closely as they roll out a
similar scheme. If it works, I'd likely be in favor of transitioning the
Persona fallback from long-lived passwords to single-use email tokens. After
discussion on the mailing list, of course.

(FWIW, dochtman and I maintain Persona)

------
adventured
I've tried throw-away email based passwords twice in the last five years.
Every time I try it I run into the same problem: guaranteed speed and
guaranteed delivery of email (both in general and that it'll always arrive in
the inbox).

Average users get annoyed very quickly when they have to wait even minutes for
an email to show up.

I still run into this problem even when using quality services such as
Mailgun.

For this approach to work, it requires at least three things

1) Much greater security for email

2) Guaranteed speed of delivery for every email, such that the throw-away
password arrives in seconds at a 99.x% rate

3) Guaranteed delivery, such that throw-away passwords arrive in the inbox at
an extremely high rate of success (at least 99.9%)

Email will never be able to deliver on these requirements. As such this system
will never be effective for deployment on a service that average users use.

------
s369610
just needs a browser plugin to check your mail via imap for any email
containing a token link to any of your open tabs and to automatically auth
you...

~~~
ttty
That seems amazing (:

------
abalone
Previous HN discussion:
[https://news.ycombinator.com/item?id=8446232](https://news.ycombinator.com/item?id=8446232)

A major drawback here is that it's incompatible with password managers which
are a better, more generally-applicable solution. Relying on email means that
if your email delivery is high latency or having an outage or an aggressive
spam filter then your account access in impacted. Keep in mind not everyone
gets their email right away -- many people (my mom) are on >10 minute pull
intervals.

~~~
PythonicAlpha
I agree, that eMail as transport media is far from optimal, but it is the only
general available media currently.

I still think that from the point of usability a passwordless solution is
better for many applications, where security is not the top priority.

Because so many applications in the web force you to have a password, security
in general is at risk. Most people get tired of passwords and use either bad
passwords or just one for all. And those passwords are endangering those
applications that are really security sensitive.

I would rather like to see, that only a few services (like banks, ...) want to
have a password and the others just authenticate their users with less
intrusive means.

~~~
abalone
_> Most people get tired of passwords and use either bad passwords or just one
for all._

That is what password managers fix. iCloud Keychain has gone a long way
towards mainstreaming this. It's built in to Safari and securely stored,
encrypted with your OS/device's master password -- which is an improvement on
Firefox & Chrome's approach, where master passwords are optional.

From a usability standpoint that email method is way _worse_ , at a minimum
due to the latency issues. Waiting a minute for an email to arrive can feel
like an hour when you're trying to log in to do something urgent. Password
managers work "magically".

For a security standpoint the email method is also worse, because it is only
usable with very long-lived sessions -- which is not the best security
practice. The article even heavily qualifies this method as not appropriate
for sites users "visit frequently".

So by the author's own logic, this method is only appropriate for sites that
_NO_ users visit frequently. Which is no sites.

Finally, the nail in the coffin for the email approach is that it's
_incompatible_ with the more general password manager solution. So those users
who do need to visit a given site frequently can't use a password manager (at
least without redirecting themselves to an alternative method, which is also
poor usability).

~~~
PythonicAlpha
This is a circular thinking: Password managers are superior to this approach,
because this approach is not compatible to password managers, the "more
general" solution.

It is like saying: "We need tv sets because tv sets are the only (valid) means
of entertainment."

~~~
abalone
Absolutely false. Password managers are superior because they don't suffer the
vulnerabilities I listed with email: high latency, outages, spam filters, and
less secure long-lived sessions.

~~~
PythonicAlpha
I already understood your point, but your argumentation is a little to black
and white at times.

------
SoftwareMaven
With the exception of automatically grabbing the token, it's pretty much the
same as BYU's SAW[0]. I worked for a startup that was trying to commercialize
this technology, but it's nearly impossible to commercialize an authentication
tech. It's unfortunate, too, because I think it would make a much better
option than most password managers.

0\. [http://isrl.byu.edu/projects/simple-authentication-for-
the-w...](http://isrl.byu.edu/projects/simple-authentication-for-the-web/)

------
mixedbit
One of drawbacks of this mechanism compared to Persona is that a web server
needs to be configured to send emails with tokens using site's own email
credentials. This isn't easy to setup reliably for a small site. A malicious
user can easily trick the server to send many tokens to different accounts and
cause the sending email to be included on spam blacklists.

~~~
tomp
How is that different from registering many user accounts with many different
emails, or using the "Forgot Password" feature using many different emails?

~~~
mixedbit
If you use Persona, the site doesn't need to send any emails (As I wrote this
is a drawback in comparison to Persona, a traditional password based mechanism
has the same problem).

------
smackfu
Using SMS for this may work better than email. Email passwordless tends to get
bogged down in little problems. Like the email is slow or goes to the spam
folder. Or on mobile, clicking a link in an email may not take you into the
web browser you actually want to use the app in. SMS at least should improve
on these two problems.

~~~
mikevm
SMS is unreliable. It may arrive in an hour, the next day, or not at all.

~~~
smackfu
In practice, it seems about as reliable as email, and faster to get to me.

------
peterwwillis
Passwordless logins, as implemented today, are less secure than password
logins.

 _Flaws in the passwordless login system:_

1\. Authentication is done on unsecured connections. With all of the shouting
over privacy and security, here we are abandoning secured, encrypted
connections for SMSes and e-mail, two unencrypted, unauthenticated, somewhat
unreliable, easily intercepted, plaintext messaging systems.

2\. Replacing an out-of-bound token with one stored purely online. Any actor
who controls the network (or your computing device) can subvert the login.

3\. Depends on a pre-existing authentication, which itself uses passwords (or
none at all), leaving you at the _exact same state of security_ as you had
before. Instead of two passwords that are the same, you have one password (the
e-mail password) that is the same, or zero authentication with SMS.

4\. No mandate for multiple-factor auth, nor out-of-bounds auth.

5\. Zero security for the tokens (cookies) stored on the user's system, so
data at rest is at risk, unless your browser encrypts cookies with a master
password. Of course this is moot considering the total lack of encryption on
the smtp/sms side and the lack of out-of-bounds auth.

 _Reasons why password logins are more secure:_

1\. Uses secured, encrypted connections to transmit secrets. Prevents man in
the middle attacks and interception of logins.

2\. Provides an out of bounds auth token. The only way to subvert this is to
intercept it as it goes into a computing device, meaning either the client or
server would have to be compromised at the time of login.

3\. Data at rest is encrypted and only the user's cached token (cookie) can be
used to steal a pre-authenticated login.

4\. Password can be unique to the service, so a compromise of one system does
not compromise all.

5\. Industry standard is already to require multiple-factor authentication to
be combined with this method for increased security.

------
pdkl95
This looks suspiciously like OpenID with the identifiers changed from URLs to
email addresses and updated to use modern pop development tools.

I _really liked_ OpenID, even though it had a few issues. The best part was
that you could put a few HTML tags at the URL you used as your identity and
delegate the authentication - but _not the identity_ \- to a 3rd party.
Because you controlled the identity, you could drop the 3rd party and use
someone else (or implement the OpenID protocol yourself locally) just by
changing some tags.

If "Passwordless" can provide this can provide the same level of _autonomy_ ,
it could easily become my authenticator of choice.

It looks like it's tied to an email account? Slightly annoying, but trivially
worked around if necessary.

~~~
tomp
I don't know how it's implemented, but I see no reason why adding/removing
emails to/from an existing account (while logged in) wouldn't be trivial to
implement.

The only thing you need to be careful with is to send a notification to the
email being removed, send notification to all emails when a new one is added,
and enforce some kind of expiry period before a removed email becomes
inactive/added email becomes active.

------
codezero
This is interesting. A lot of social networks use this sort of authentication
for their email notifications, and weekly/daily digests, but don't treat it as
a first class login.

Facebook, LinkedIn, Twitter, Quora, etc... use a short expiration on these,
but if you ever forward one of your new notifs to a friend, they will end up
logged into your account, which is surprising. It usually only lasts for the
session, and some are pretty good about double checking if you are coming from
a new location or have cookies for another account set :)

For longer lasting sessions, email security seems like a big concern,
especially since most people keep all their email forever (gmail) and it's
easy to search through.

~~~
thesumofall
Almost :-) The tokens are one-time only. Afterwards the session is keeping
track of the user. Another login requires a different token.

Regarding the emails of Facebook, etc.: Great example, actually! I guess the
problem really is that they don't make it obvious to users that they actually
hold an authentication token in their hands.

~~~
codezero
Yeah I assumed they were one-time only. In examples I've seen, each link had a
different token, so if you forwarded something, one of the links may work if
you hadn't clicked that particular one.

When ever I explain this to people, and forward them one of my notifs from
Facebook, they get pretty paranoid and shocked, then eventually accept it
because of the convenience :)

------
Oblouk
I do not see the benefit of this from a usability standpoint.

From a security standpoint it seems like an absolute nightmare. If you lose
the password to your email you could lose access to all your accounts.

Most people do not own their own email server and so this could have
catastrophic security consequences.

Of course the sites could check for IP location consistency but in order to
spot security threats early you would need to track logins to multiple sites.
The only way to do this would be to either give another third party company
the ability to track logins and implement fail safes. At that point it begins
to operate a lot like the companies which allow third party authentication
through Facebook/Twitter/Email.

~~~
penprog
Considering that for most websites one can easily reset the password to your
account if they have access to your email, this adds no extra security risk
(for those situations which are most common websites eg. Amazon, facebook,
twitter etc). So this is NOT catastrophic for security because the current
situation is already like this.

For websites where security is a larger issue, this obviously wouldn't be the
solution.

------
mankins
I implemented something like this as an alternative to the OpenId logins when
I was at Fast Company. I believe it's still in use there if you click the
person icon to login at the top right, select other options, and then "send me
a one time link". Try it out?

We did this because we had people that didn't have Twitter or Facebook logins
and needed to use some service that we had. I didn't want to build out a
password database so came up with this work around.

Surprisingly we didn't receive that much hate mail about it, and we have a
fair amount using it per day, so I'd say that people like it.

------
mtck
Is there any advantage of this over using Oauth to 'Sign-in with Google/FB'
other than being platform agnostic? similar workflow except tokens are being
exchanged between server-server vs sever-email.

~~~
marco1
No, except that SSO via such a service is _more_ secure than the email
approach. However, being platform agnostic is quite an important reason.

------
konceptz
One thing I like about having different passwords and logins for each site is
that I don't have to worry about cascading failures.

This seems like it isn't getting rid of user/pass authentication, it's just
pushing it onto someone else, in this case your cell or email provider.

Other users have correctly stated that this doesn't increase the attack
surface, however it does increase the value of a single vector.

Please correct me if I've missed a key point in the OP, I didn't spend lots of
time reading the finer points of the implementation.

~~~
twodayslate
Your email is already a single vector. Most sites have a "forget my password"
link and all you need is the email account to reset the password and access
the account.

------
ravloony
Doesn't this mean that an attacker now only needs the password to the email
account and all these passswordless services get compromised as well?

~~~
rikkus
Yes. But this is the case with the current 'forgotten password' system.

Securing your email account can be done without 'only' using a password. I use
2 factor auth on my google accounts, for example.

~~~
peterwwillis
Forgotten password systems are supposed to use challenge questions to
authenticate the user before resetting the password. (Of course, those same
sites often provide a way to reset using challenge questions and _without_ an
e-mail confirmation, which is how celebrity accounts get compromised)

------
anywherenotes
There are a lot of websites that are not worth the hassle of registering for,
but this can make registering on them easy and they may get more
registrations.

For important accounts I would still prefer a password only stored in your
head and two phase authentication. But for various forums, this type of a
setup is better than using third party password manager or same-username-
password combination for general purpose.

------
drikerf
Great idea, I can see that this would be awesome on services I use seldom and
often forget my password anyway. But do the average user really care enough to
bother with email? or for SMS, will they give away their phone number?
Remembering users for a long time also opens up for other breaches. Anyway it
is awesome that people are working alternatives!

------
passfree
A similar idea was discussed here ([http://www.gnucitizen.org/blog/simple-
universal-authenticati...](http://www.gnucitizen.org/blog/simple-universal-
authentication-system/)) in 2008.

------
e0m
I think we sometimes forget the number of users who would try and get to your
service, then bail because they need to boot-up Outlook, or work in a building
with no cell reception.

------
thesumofall
Someone just made me aware of www.cotap.com - It's probably using a different
middleware, but I think a perfect example of where passwordless login makes
great sense!

------
throw7
This requires javascript on the client no? That's a no go for me. The little
demo site fails for me.

