
One Less Password - cpeterso
http://notebook.ideapublic.org/2014/one-less-password/
======
abalone
Not a bad idea but the chief drawbacks I see:

1\. Needs a very long-lived session to be convenient. Elsewhere they note
their's is a whole year.[1] That's a long time to go without reauthenticating
a client!

2\. Authentication is or should be a much more common event than recovering a
lost password, and now that's totally dependent on your email provider. One
concern is latency.. a minute can feel like an hour while waiting to log in to
your account to do something urgent. But also worrisome is provider downtime,
spam filters, etc. all can block you from accessing your accounts.

Of course the way they "deal" with #2 is by just trying to avoid
authenticating you very often (#1), which is not a generally-applicably
awesome security practice. Might be ok in some cases but I wouldn't classify
that as an overall "better" way to sign in.

I think a better way to solve this is at the browser/OS level with built-in
password generation and management. And that's actually a third drawback to
this approach.. it's incompatible with password managers.

[1] [https://chrisdecairos.ca/one-time-passwords-
pt-2/](https://chrisdecairos.ca/one-time-passwords-pt-2/)

~~~
espadrine
I feel like we're missing the elephant in the room.

The solution they have isn't an authentication system. It is a system that
relies on an existing authentication system (your email provider's system) to
work.

This is essentially the same as OpenID Connect: you really log in with your
email host, be it Google, Yahoo, whatever. It is better, because your websites
don't have to support the use of a dozen different vendor-specific login
buttons.

But the real authentication happens when you enter your password to access
your email.

Therefore, when I read:

> _I think a better way to solve this is at the browser /OS level with built-
> in password generation and management._

All I can think is, it depends on who you trust: the entity that secures your
mail, your contacts, your calendar information, or the entity that secures
your passwords to get there?

We can have a world where identity is federated through your email account. We
can also have a world where it is federated through your browser account. They
are fundamentally similar, and I have no way to know which of Gmail or Firefox
Sync are more secure, but I do know that they're both inconvenient as is.

Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I
don't often have my phone), and wants me to have a backup email address for
recovery purposes (which I cannot accept from my main identity holder because,
well, it is the main one).

Firefox Sync doesn't enforce the use of a master password for all users, which
can easily give the appearance of security. Besides, it won't always detect
password fields and won't auto-login when it sees them. In addition, it
doesn't have the (UI for the) ability to switch users on the browser — you
need to use a private window for that, but then your passwords are still
shared with other users. Finally, it doesn't generate strong passwords for you
(which makes sense, most websites offering a password have stupid rules).

From the website's side, implementing a login solution relying on an existing
email provider is way easier and more secure than relying on your browser's
Sync system.

So, is it really a better way to solve this? Not currently.

~~~
ap22213
A few thoughts about the current de facto authentication 'standard':

1\. The majority of my accounts are tied to my email account. Now, I can't
easily change email providers; I'm locked in, for the most part.

2\. Email is slowly dying and will be mostly extinct before long. Most people
under 20 don't use email except for authenticating with web sites. Email was
traditionally used for asynchronous one-to-one (or one-to-many, in some cases)
communication. But, new services have risen that do this better.

3\. The near-ubiquitous rise of mobile and smart phones: although you may not
have a phone nearby, my phone is pretty much the only thing that I always have
with me or nearby. So, I want sites to authenticate me with my mobile device,
not email. I see mobile device (an identity proxy) becoming more ubiquitous,
not less.

4\. But, sometimes I want to authenticate anonymously.

5\. I don't want to have to trust my email provider (or any 3rd-party
provider) to safely and privately store my account information.

6\. And, if I lose or break my phone, I don't want to lose my identity - I
want an easy way to encrypt and store my identity at multiple backup
locations.

------
janfoeh
I like the idea. The downside is of course having to switch between the site
and your email.

One could bridge that gap by adding two headers to the authentication emails -
one containing the URL where the sign in request originated, and one with the
sign in URL that must be visited.

A browser extension could then check your emails, and if an incoming mail
matches the sign-in page of the current tab, log you in directly.

~~~
mrb
Bingo! Automating email-based authentication would indeed be pretty cool. In
fact, extend this concept a little further, and you will realize that email
itself is the ultimate platform to build programmatic exchange of information
between persons and services. I wrote an essay about all the possibilities
this would open:
[http://blog.zorinaq.com/?e=76](http://blog.zorinaq.com/?e=76)

~~~
hug
It's not the _ultimate_ platform. Arguably, it's not even a very good
platform. What it is, however, is the best platform we currently have.

The idea of using email for password exchanges is fraught with difficulty, and
not only because there's a lot of terrible email providers that don't even
support starttls on their mail servers. Net-savvy people have fought a war to
have HTTPS implemented across the web, can you imagine how hard it's going to
be to get people to fight for implementation of security they can't even see?
Ask your nearest non-technically minded friend if he knows if his email is
encrypted in transit, and then ask him if his bank website is.

Someone elsewhere in the thread mentioned they'd only just started using key-
based SSH login, and how it seemed to them the best thing since sliced bread.
Extend that a little further with keyphrase protected keys and ssh-
agent/pageant/whatever macs use, and you have a much, much better platform
than "emailing a temporary password." The problem I see with implementing
something like that is getting it off the ground.

~~~
thibauts
Whether we like it or not email or its successor is bound to be the natural
authentication platform. Something is happening here, I'd pay attention.

------
thedufer
I implemented this style of login in the app I'm currently building. I don't
think its necessarily appropriate everywhere; the reason I decided to use it
is that its the type of service you very rarely log into. For things like
that, a large portion of logins are (anecdotally) going to end up going
through the forgot password flow anyway.

I will admit that not being responsible for storing passwords was one of the
reasons I used it. I'm by no means a security expert; one less thing I can
screw up seems like a major plus.

~~~
thenduks
I've done the same thing in a few prototype-style apps I've built too. Not
only do you not need to store passwords, but you can just ignore a whole area
of UX.

Enter email to signup -> link gets emailed. Enter email to login -> link gets
emailed.

I use JWT for this and it really makes it easy to get started on the part of
the project that matters... and sometimes (not always) I think it's probably
going to be fine to leave it this way.

------
atmosx
A modern password manager (e.g. 1Password) seems like a way more natural
solution that this. Not to mention that many services do not use
smtpd+ssl/tls.

~~~
scottmotte
I disagree with this. I see services like 1Password as a bandaid for the tech
savvy population. They are solving the password problem well, but only if you
seek out the tool and understand the need for the tool. Approaches like the
author's here solves the password problem for the majority of the population -
the non-tech savvy population.

To your second point. Yes, this is true. But this is improving [1]. I'd add
that forgot password functionality carries the same risk, and I'd add that the
more likely chance of your password being 'discovered' is by brute force or a
website hack storing passwords in plain text - rather than intercepting email.

[1] [https://sendgrid.com/blog/sendgrid-and-the-future-of-
email-s...](https://sendgrid.com/blog/sendgrid-and-the-future-of-email-
security/) (I work at SendGrid)

~~~
kalleboo
> They are solving the password problem well, but only if you seek out the
> tool and understand the need for the tool

How about Apple's Keychain? iOS and Mac users get suggested auto-generated
passwords that are then automatically saved and synced across devices with no
extra installs or options.

------
ChuckMcM
I really like this, I was thinking the other day when I used a site that I
rarely use, and went through the whole 'forgot resend reenter' password thing
that just that could be the 'standard' way of dealing with low impact sites
and wouldn't force a password to be generated. It does imply the mail path is
workable but that seems pretty common these days.

------
BinaryIdiot
It's clever but I wouldn't use it. First the user experience of going from one
channel (web) to another (email) isn't very natural but the second and biggest
reason is that it turns an email account into a central authority to access my
other accounts from.

Some say email is already like that but it isn't with services using two
factor authentication.

I don't think there is an easy and intuitive way to get rid of passwords
without involving some sort of physical component that stays on yourself.

~~~
iandanforth
What is your workflow that this would be any more difficult? The first time
you sign up for a service you almost always have to do this anyway for
confirmation. If you then select the "Remember me" path, your primary computer
is whitelisted and you don't have to do the round-trip.

Due to "Forgot my password" workflows email is already a central authority. If
you have two factor auth set up for your email account then you're already
pretty well protected and having each and every service use a different two-
factor method provides diminishing returns in security.

The funny thing about this proposal is that it is _exactly_ the way my non-
technical family members use _every_ service. They don't bother with passwords
they just use reset links every time. They don't have to remember anything and
it's a common workflow.

~~~
BinaryIdiot
> What is your workflow that this would be any more difficult? The first time
> you sign up for a service you almost always have to do this anyway for
> confirmation. If you then select the "Remember me" path, your primary
> computer is whitelisted and you don't have to do the round-trip.

This assumes one (or n) devices that belong to you. I typically have to log
into multiple services using a large amount of computers for work. In my use
case this would be tremendously annoying whereas two factor I can simply log
in like normal and type in the code from my phone's app.

> If you have two factor auth set up for your email account then you're
> already pretty well protected and having each and every service use a
> different two-factor method provides diminishing returns in security.

I disagree; it prevents someone from getting into my email due to a
vulnerability and then being able to get into every other service I'm
connected to. Each service I use would, ideally, have two factor (though I
obviously do not think two factor is perfect but it's better right now than
most alternatives in my opinion).

~~~
iandanforth
Interesting, it's clear that in your use case it would be more of a hassle,
but in response to the second point it seems you're ok with the hassle of two
factor authentication for many services.

I guess whatever the scenario 2-factor + email round trip is more of a hassle
than 2-factor + password.

Thanks for your response!

------
pmichaud
I remember this idea from a while back, and I still think it's not going to
work. It's too cumbersome to have to access your email every time you want to
log into something. I love the creativity of the solution, but I just don't
think it's workable on a large scale.

~~~
ricardobeat
Now that we all have push email in our smartphones, it's not nearly as
cumbersome. I already need to pull out my phone every time I want to access a
Google app, having 2FA enabled.

~~~
CaveTech
But clicking the link on your phone would only log you in on your phone, no?

So your phone can't aid you here. If you're using any type of setup that
doesn't use instant-push emails on your desktop, logging in will be very
cumbersome.

~~~
callahad
The email also contains a short, one-time-use password that you can use
instead. Look at the email on your phone, enter the password on your laptop.

I've wanted to move Persona in this direction for a while. I'm really excited
to see if Webmaker is successful with this auth model.

------
downandout
This is still nothing more than a password...it's essentially just a password
that is emailed to you. I've never understood why we can't instead
authenticate ourselves to our browser or device, and get people out of the
habit of authenticating to individual websites. This would eliminate phishing
and greatly enhance security. Touch ID is a big step in this direction, but
still can't be used for websites.

When authenticating, the browser could just send the user's public key, and if
a user with that key is in the system, it replies with a session key encrypted
with the user's public key. If browser companies would get their act together,
we wouldn't have as many authentication issues as we do today.

~~~
michaelmior
It is possible to use public key authentication with most modern browsers (not
sure exactly which browsers support this). However, it's true that browsers
currently don't provide any method to authenticate the user with the browser
itself. (Although you could argue whether or not this is necessary since the
user has presumably already authenticated with the machine running the
browser.)

The biggest problem is that the user experience is pretty terrible for
generating and managing the certificates used for authentication. There's also
the fact that the certificates are stored by the browser with no obvious
mechanism to log in from another machine.

~~~
stephenr
I've been wondering whether the concept in the article could be expanded out
using client auth certificates.

So instead of clicking the login button and getting an email __every time
__you need to authenticate (or using really long sessions), you use the "email
to login" method __once per new device __. The resulting page takes the user
through creating and uploading a client auth certificate, and stores it (along
with a user provided device name to allow revocation).

In-browser cert+key generation is not perfect by any means but it certainly is
possible - it's how providers of S/MIME certificates [1] are able to give you
a signed certificate without you manually creating a private key+csr and
uploading it.

[1] e.g. [https://www.comodo.com/home/email-security/free-email-
certif...](https://www.comodo.com/home/email-security/free-email-
certificate.php)

~~~
nairboon
TLS client authentication [1] is doing this already.

[1]: [http://www.browserauth.net/tls-client-
authentication](http://www.browserauth.net/tls-client-authentication)

------
sarahj
This essentially mimics my login flow to every site I only use occasionally
(e.g. twitter) and therefore can never remember the password for:

1\. Go to login

2\. Forget password - click reset password

3\. Go to email, find reset password email

4\. Login.

I wouldn't really mind if this became more common. I don't trust password
managers (and access the internet from so many different devices that the only
common thing they share between them is that I can access my webmail client or
email on my phone.)

~~~
Lost_BiomedE
LastPass was considered secure on HN in the past, has this changed? Or is
there a reason you don't like it? Not attacking, just curious about my own
security.

~~~
sarahj
I'm sure many password managers, including LastPass, meet the security bar for
the threat models of most people.

However,

* I don't trust any software that uploads data to a centralized service (encrypted or not)

* Especially when that software is not open source / free software.

~~~
__P
1Password doesn't do that.

------
jordanpg
The cynic in me observes that although this post is couched in the language of
an improved UX, what it also does is absolves Mozilla from keeping any
(hashed) passwords stored in their databases. Only tokens with a very short
shelf-life.

(Hashed) Password storage is moved to a third-party database (the email
provider). Presumably the client "remember me" links are meaningless by
themselves.

~~~
dekz
The authentication providers are more than just email (the article mentions
phone and SMS tbd).

I'm not sure what you're saying here:

> (Hashed) Password storage is moved to a third-party database (the email
> provider)

There is no hashed password? It's just a challenge response using an
alternative path.

~~~
jordanpg
My assumption is that a "login key" is essentially a large piece of data that
would be prohibitively inconvenient to use outside of an email account, text,
etc. Analogous to a large session cookie without an expiration date.

In contrast, a password is designed to be used from any login point.

In this regime, unless the optional password is used, there is no hashed
password stored on Mozilla's servers. Only a copy of the hash of the "login
key" is stored, so the attack surface is considerably shrunk if you are
attacking Webmaker users.

~~~
jordanpg
More technical details here from the post:

[https://chrisdecairos.ca/one-time-passwords-
pt-2/](https://chrisdecairos.ca/one-time-passwords-pt-2/)

I'm not totally clear about what the different between a "login key" (short-
lived, pronounceable) and whatever is contained in these semi-permanent login
email links (~1 year, presumably non-pronounceable).

------
mderazon
I like this idea for mobile apps a lot.

In mobile the sign up flow can even be more streamlined using deep linking:

1\. User enters email address.

2\. Opens email client and click the link.

3\. Link contain app specific schema myapp://login?token=cold_fish etc.

4\. App opens and verifies the token with the server.

5\. User is logged in.

User has to enter only email address as opposed to email + password (and
sometime password confirmation) Then only needs to click a link in email
client to sign up.

------
netheril96
Isn't email transferred in plain text? This is not very secure in my mind.
Granted, nowadays a lot of service lets you reset your password through email,
but that is only a one time thing. Now the whole system is dependent on
someone not introspecting the packets flowing in the Internet.

~~~
AReallyGoodName
That's historically true but TLS is now really common on both servers and
clients. In fact most major email clients I've seen show a warning if the
server only supports plain text.

Thunderbird shows a large modal "WARNING! Server mail.myhost.com does not use
encryption" dialog.

~~~
jcrites
I don't know if it's fair to say email over TLS is really common yet. It's
getting there, but Google's email encryption in transit transparency report
shows that only 57% of inbound messages to Gmail were sent over TLS. Outbound
72%.
[https://www.google.com/transparencyreport/saferemail/](https://www.google.com/transparencyreport/saferemail/)
(this is largely concerning server-to-server communication, rather than
client-server, but server-server communication happens whenever emails are
sent across domains).

To be fair those inbound reports are potentially bloated by a lot of spam that
no one reads or cares about. It would be interesting if Google disclosed what
percentage of messages that end up being read are sent over TLS (or non-spam
messages generally). But we can also see that several top 10 sending domains
do not support TLS at all (adsender.us, constantcontact.com, grouponmail.*,
sailthru.com - mostly advertisers). Luckily the top receiving domains support
TLS (which look like other big-name ISPs).

Compared to website TLS, email TLS as commonly implemented has two significant
challenges beyond these percentages. First, since TLS is established by the
STARTTLS extension protocol within an existing plaintext SMTP connection, it's
easy for an attacker who can modify communication to force it to remain in
plaintext (simply don't advertise the TLS capability). Second, that previous
attack is hardly even necessary: most email senders are willing to establish
connections to receivers who present self-signed certificates. The same
scenario when browsing a website will show a security warning and
recommendation not to continue. The reasoning goes: it's better to use TLS
even with a self-signed cert than fall back to plaintext. There's no human
involved who can make a judgment call to abort, like there is when browsing a
website. So, while email TLS with self-signed certs may be helpful against
passive dragnet surveillance, it's little defense an attacker who can
intercept and modify the communication: the attacker can simply present his
own self-signed cert instead, and the email will flow.

Solution ideas: Devise a standard by which messages can be stamped "TLS only
or don't send", and another standard by which domains can declare their
intention to support TLS. Senders will remember that the domain is TLS-enabled
and refuse to fall back to plaintext; and will require a certificate from a
reputable CA under either protocol.

------
scottmotte
I too would "like to see [this approach] used and pushed further by other
designers and developers."

I'm one of those who have been trying to do so. I created an open source
approach called Handshake.js that is re-usable for developers. [1]

I presented this topic to a good crowd at JS.LA [2].

At the current time, I'm finding developers still hesitant to jump into the
approach. Passwords are familiar and there are many developer tools/libraries
to quickly setup the defacto username/password approach to authentication.

[1] [https://sendgrid.com/blog/lets-deprecate-password-email-
auth...](https://sendgrid.com/blog/lets-deprecate-password-email-
authentication/) [2] [https://vimeo.com/90883185](https://vimeo.com/90883185)

------
rakoo
Ah ! I built this a few months back:

[https://github.com/rakoo/xauth](https://github.com/rakoo/xauth)

It uses the same idea as in the post, ie the "lost password flow for login",
but with XMPP. The latter gives you much higher flexibility in that it
actually is thought out as a programmable protocol. You try to login, the
server sends a token to any of your connected clients via a bot message, you
just repeat it to the bot and you're then granted access.

I feel there is high potential here, and there even is an official XEP
([http://www.xmpp.org/extensions/xep-0070.html](http://www.xmpp.org/extensions/xep-0070.html))
for this.

------
RexRollman
Playing with NetBSD the other day, and bored, I created an SSH key for the
first time and was amazed that I had not been using this for forever. I think
keys could replace passwords, or at least, cookie based logins.

~~~
bajsejohannes
Client-authentication has actually been supported in SSL for a long time [1].
Unfortunately, there seems to be little interest in using that form of
authentication in browsers. A big part of that is probably making a compelling
user interface and teaching users how it works.

[1]
[https://en.wikipedia.org/wiki/Transport_Layer_Security#Clien...](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-
authenticated_TLS_handshake)

~~~
nairboon
[1] summarizes why TLC client auth isn't wide spread, but he also proposes
some TLS extensions to improve client auth. Such as Origin-bound certificates
[2] so that the user does not have to choose which certificate to use for
authenticating.

[1]: [http://www.browserauth.net/tls-client-
authentication](http://www.browserauth.net/tls-client-authentication) [2]:
[http://www.browserauth.net/origin-bound-
certificates](http://www.browserauth.net/origin-bound-certificates)

------
MicroBerto
What's funny is that we're basically doing a very similar thing at my startup,
PricePlow ([https://www.priceplow.com](https://www.priceplow.com)), and it was
actually inspired by discussion earlier here at Hacker News.

It works very well for our purposes. We don't need crazy security because we
store no important personal information -- just product preferences. It's
insanely easy on the users.

I guess I should get back to blogging about my entrepreneurial lessons
learned, as this has been one of many of them....

------
thesumofall
There is a fully fledged implementation for Node.js
[https://passwordless.net](https://passwordless.net) (Disclaimer: I'm leading
the development)

------
harigov
So instead of directly logging in using the ID provider like
FB/Google/Microsoft, which are also the email providers, you send an email to
those accounts and ask user to take one extra step of checking and clicking
the link. It seems to be inefficient. A much better solution should be for the
devices to support accounts natively and integrate authentication directly
into the platform.

~~~
hmsimha
The idea seems to be that you only have to do this once, then you remain
authenticated for every service that integrates with this authentication
service. You don't have to remember another password or place trust in a new
service not to mishandle it.

This seems like a solution that completely replaces the need for every website
to manage their own user signups, which is something you still need to do even
if you integrate with Google/Facebook/etc. because not everyone has an account
with those and signing up for one is less trivial than having a sign-in link
sent to your email.

------
codinghorror
How is this any materially different than the "I always forget my password and
I always use the forgot password link"? I guess you don't have to pick a new
password each time? But you could just rapidly type in gibberish and achieve
nearly the same effect, no real password, login via email.

~~~
esolyt
Well, you would have to type the same gibberish twice though.

Besides, I don't think they are claiming to be innovative. I think they just
point out there is a redundant step which we can remove from the process.

------
jplarson
The biggest reason for me to pass on implementing an approach like this is
what I THINK is the actual most common use case for a typical user when
logging into a site at which they are a regular:

They're doing so for the nth time, and on the (or a) device they usually use,
and thus their browser (or other password manager) has already got their
password remembered and thus it is pre-filled in.

Having to click back and forth between email every time you log in seems way
clunky relative to that, which for me is something above 90% of the instances
I log in to some web application.

Couple that smoothness with picking a non-reused, strong password for a web
application (which password managers make actually practical) and the friction
in the user login experience seems to have little if any upside.

~~~
troymc
In the email, you can click "Sign in & remember me". I guess that sets a
cookie in your browser, so next time you come back, you'll still be logged in
(until the cookie expires).

------
LukeB_UK
Every time I've heard of this system, I've thought that it would make it
clumsier to access an account.

I go to a site and my intention is to stay on that site throughout whatever
I'm doing there. If you force me off your site for something like logging in
(where it's the point of 'I trust your site, give me access') then I've lost
focus and you've put your experience in someone else's hands.

If I was doing this, I'd have to open a new tab, go to GMail, wait for it to
load, find the tab within GMail that has the email and then click the link.
Every so often, I'd probably have to put my Google password in too. That's a
lot of effort, considering that your site probably isn't that significant to
me.

~~~
Raphael
Most people keep their email open, and many have push notifications.

~~~
LukeB_UK
My experience is to the contrary, on personal devices, people don't seem to
keep their email open.

If by push notifications, you mean mobile devices, then surely that would only
log them in on that device rather than on their computer?

~~~
ncallaway
Short expiration one time use codes can allow you to authenticate on devices
different than the one that receives the email.

------
imaginenore
I actually prefer Reddit's version - email is optional, while password isn't.

------
pulkitpulkit
I really like the way TranferWise (transferwise.com) automatically signs me in
when I load the page. It's a way to transfer money online so has to be secure,
but uses my email authentication to verify it's me. I don't even have to click
a sign-in button! I'm surprised this hasn't caught on more...

[https://transferwise.com/support/customer/portal/articles/16...](https://transferwise.com/support/customer/portal/articles/1663507-when-
i-log-in-the-site-only-asks-for-my-e-mail-and-not-for-any-password-)

~~~
jfroma
The link describes something very common.

The only difference I can see is that they ask you the email to figure if you
are coming from yahoo or Google while the most common pattern is to show two
buttons.

I don't think asking your email is a good idea, email is a something they
should ask to the identity provider instead.

------
FlailFast
I like this idea a lot, but given the centralization of authority to a user's
email account, I do think it requires beefed up security for however the user
accesses their email---i.e., would be great to allow this only for users who
have 2FA enabled on their webmail, although I have no idea how you'd check or
enforce that.

Actually, the "lost password" flow already assumes email as a single point of
failure, so I suppose my 2FA comment is moot (in other words, we should be
pushing for 2FA for accounts regardless of their password approach on other
accounts).

~~~
esolyt
> but given the centralization of authority to a user's email account

This is already the case right now. An attacker who has access to your primary
email account can gain access to any of your accounts using Forgot Password.

> the "lost password" flow already assumes email as a single point of failure,

Exactly. I think that was the inspiration for the idea. If we have a single
point of failure anyway, why not just use it directly to login?

~~~
jordanpg
Yes. This just offloads the security burden from the Webmaker service to your
email provider. It means one less password, but a compromise is still
catastrophic.

If the goal is to separate the need to remember complex passwords from the
application, then a password manager makes much more sense (ideally with 2FA).

In the long game of improving token-based security, this is a step sideways at
best.

~~~
ncallaway
With this method I'm not seeing how an e-mail compromise is any more
catastrophic than a site that offers a "forgot my password" flow.

That is to say, yes, a compromised primary e-mail _is_ catastrophic, but seems
like an already accepted risk. Why is this worse?

~~~
jordanpg
Assuming an email compromise is catastrophic, as pointed out earlier in this
thread, one might as well use a password manager, which allows for maximal
password strength, possibly 2FA, total control over the password database,
etc.

I didn't mean to imply that this was worse, only that it doesn't really change
the threat.

------
joesmo
The main flaw with this idea as well as pretty much every password reset flow
is that email itself is insecure. If I want to attack the login system and I
have the ability to intercept the emails at some point, I essentially get
access to the link/code in plaintext and now have access to the account. The
difference might be that there will be a much higher volume of emails from a
system like this than from one that just uses email for resetting passwords,
though that's not guaranteed. I'd like to see a system that address this
issue.

------
imrehg
Startup Digest event submissions use similar method: no account, every login
is an email sent to you. The problem I have is that I do use a password
manager and like that much a lot more than switching back and forth of email
and the site. If I go to your site, I don't want to go to my email...

It really feels like they want to solve my password storage problem for me, in
a very opinionated manner without any alternative for me, and while it might
be a good solution, it does not feel like one (for me).

~~~
guelo
It says you can turn off passwords if you'd like.

------
lazyjones
Does this handle concurrent logins from multiple devices reasonably? If every
login essentially resets the "password", either all other existing sessions
are terminated (bad usability) or kept (possibly insecure).

The linked more technical description suggests that the latter is done
(sessions on trusted devices are valid for 1 year), so you apparently cannot
stop someone with a stolen device from accessing your account (while the
session is active / the cookie persists).

------
cpeterso
Here is the Mozilla Webmaker blog post with a more user-centric discussion of
the password-less system: [https://blog.webmaker.org/one-less-
password](https://blog.webmaker.org/one-less-password)

I was initially concerned that email is insecure, but then I remember sites
already use email for password reset. :) My bank does something similar by
also remembering my personal computers by browser fingerprinting and/or IP
address.

------
marco1
We shouldn't abuse email for this. Any one of LastPass, 1Password, KeyPass
etc. or SSO with Google, Facebook or Twitter can do this way better. You will
probably be using extremly long and random strings, i.e. you're storing secure
tokens there. You can't call those passwords any longer -- and we should
forget about the notion of manually creating and then remembering passwords to
sign-in.

------
jsudhams
If the service is not going to contain any privacy related stuff or need not
be so secure why not just keep the cookie after typing in email address.

What i do is i keep all worthy sites'password on the password manager and the
rest of the site follow a pattern based password or a common simple password.
For e.g. i typically use some this "keepass"or domain of visited web + keepass

------
esolyt
This makes a lot of sense. On every device you would use to login to some kind
of service, you already have access to your primary email. Clicking a link is
easier than typing your password. It also seems to be safer. Your account is
safe as long as your primary email is not compromised, in which case the
attacker would gain access to your account by Forgot Password anyway.

------
aidos
I've wondered for a while why this pattern isn't more common.

In the past I had thought it would be great if instead of email it could push
to your phone so a message would pop up saying "confirm login? Yes/no". It
would be a really simple option from a ux perspective but screw going anywhere
near making the crypto tech to support it.

------
droopybuns
[https://fidoalliance.org/](https://fidoalliance.org/) is a much better idea
and worth investing in instead.

Passwords must die. We need to get to the point where there is a modular
mechanism for authentication so that individual devs never are tempted to
create a users table and add a note field for password storage.

~~~
MichaelApproved
From the video on this page[0], it took 12 steps to link a fingerprint with
fido. That doesn't seem like a realistic solution.

[0]
[https://fidoalliance.org/adoption/videos](https://fidoalliance.org/adoption/videos)

~~~
harshreality
That's specific to that implementation.

1\. Navigate to Settings, Finger Scanner, Pay with Paypal

2\. Select Install FIDO Ready Support, then Install NNL fingerprint scanner

3\. Select Link to Paypal, then Link Fingerprint

4\. Login to paypal with username and password

5\. Agree to terms

6\. Swipe finger to link fingerprint

7\. Install paypal app.

1 is obviously mandatory. 2 could be preinstalled. 3 could be combined, but is
mandatory. 5 is stupid. 7 should be already installed if you use paypal.

End result: find the right settings area, select link fingerprint to paypal,
login to paypal, swipe fingerprint to link, done.

Don't criticize FIDO based on some half-baked implementation. Any problems you
have with the setup flow are either Paypal's fault or Samsung's.

~~~
MichaelApproved
That halfbaked implementation is the featured video on their website. As
someone new to fido, I was trying to learn about it and their website was very
confusing and this featured video wasn't a great example of the technology.
Those are not good signs of the technology.

~~~
harshreality
They're trying to point out that it's usable today with paypal and the S5.
They have no control over the steps Paypal and Samsung require to set it up.
And although the 12 steps or however many there are are not ideal, it's not as
if they left the setup for the user to figure out; all you have to do is
follow the video. You're making a huge deal out of some extra steps on a one-
time setup.

Don't blame the technology or the FIDO alliance when that video is about the
S5 and Paypal, and the video is hosted on Paypal's youtube account.

The new yubikey neo (as of October) supports FIDO, but I don't know about
client (browser/mobile) support middleware, and it requires nfc or full sized
usb.

------
kylequest
Good option for B2C services that are not that important (pretty much most of
them actually :-)).

Email delivery problems is a factor that needs to be considered though.

Stolen "remember me" cookies is another factor... The password stealing
malware will start harvesting those cookies instead of passwords (it's already
happening in some cases).

------
TomGullen
Submit phone number, and it SMS's you your password.

If I steal someone's phone, I get access to any system using this.

If I buy a sim card off someone, or buy used sim cards, I could also gain
access to some potentially high value targets if they use this.

If I 'borrow' my phone of someone, I can steal things from them if the sites
using this have value.

etc etc.

------
frewsxcv
Less -> Fewer

~~~
pluma
No. [http://www.thatdanny.com/2008/11/20/one-fewer-or-one-
less-a-...](http://www.thatdanny.com/2008/11/20/one-fewer-or-one-less-a-
definitive-answer/)

~~~
Tyrannosaurs
This article claims that the Guardian style guide was unhelpful. Possibly he
should have read it:

"fewer/less: fewer means smaller in number, eg fewer coins; less means smaller
in quantity, eg less money"

Simply put fewer is for things which can be counted, less is for things which
can not. So you have fewer cylinders of air, but less air. If you can say "one
X" and have it make sense you should use fewer, otherwise use less.

That's the rule as it's meant to work, the more interesting question is "does
the rule matter any more?", to which I'd answer probably not.

You don't see supermarkets with "5 items of fewer" lanes and most people don't
really see any difference between the two terms. The reality is that language
continues to evolve, as it has always done, and the distinction is really now
just one for pedants (guilty as charged). If you need proof of this then the
just look at the figures in quoted blog post (assuming they're even vaguely
right), which suggest that most Guardian journalists are ignoring their own
style guide and their sub-editors (a job title which pretty much comes with
pedantry in the job spec) are letting them.

~~~
topbanana
> You don't see supermarkets with "5 items of fewer"

That's why I shop in Waitrose [http://scaryduck.blogspot.co.uk/2011/05/death-
to-ten-items-o...](http://scaryduck.blogspot.co.uk/2011/05/death-to-ten-items-
or-less.html)

~~~
Tyrannosaurs
Ha, why doesn't it surprise me that Waitrose have that?

------
mcmillion
I'd much rather just use a password.

------
flowerpot
Interesting, I would like to see how non-tech users evaluate the user
experience of this.

------
nicarus1984
What if I want to have this authentication process on my email account itself?
:) The only other option (soon to be available) is SMS. Seems a bit too
limiting and maybe not completely practical.

------
alexsmolen
I built an open-source Rails engine for something like this:
[https://nopassword.alexsmolen.com](https://nopassword.alexsmolen.com).

------
bibonix
Sounds like a good idea, but how many sites/companies will adopt it? There are
tons of similar ideas, but none of them are as popular as login/password...

------
nathancahill
Flask-Security supports this experimentally. I love it. It's much less of a
hassle than you might imagine, having to click a link in an email.

------
cpeterso
How does the user log in if they've changed their email address (e.g. switched
ISPs and not using a gmail address)? Authenticate using SMS?

~~~
mderazon
SMS is one option, but then you end up with the same problem - what they've
changed a number...

The system will probably have to give a way for the user to change email
address while the user still has access to the old email address.

This is something that wasn't mentioned in the article but should definitely
be solved.

~~~
PythonicAlpha
>The system will probably have to give a way for the user to change email
address while the user still has access to the old email address

Any reasonable web-application today has (or should have) a possibility to
change eMail address.

------
cameronehrlich
I think this could be a very elegant solution.

------
jchysk
LaunchKey. No Passwords. [https://launchkey.com](https://launchkey.com)

~~~
hyyypr
From what I understand, this is basically the same idea as OP, technically
speaking.

Except the UX is sexier.

------
skion
"Passwords might be useful for someone who works on a public computer at the
library."

Key loggers anyone?

------
davidkhess
I don't think storing authentication tokens in people's email is good UX and
raises expiration issues.

Here's another take on how to get rid of passwords: The Password Manifesto

[http://www.tech-spelunking.com/home/2014/9/5/the-password-
ma...](http://www.tech-spelunking.com/home/2014/9/5/the-password-manifesto)

~~~
PythonicAlpha
I think these two methods are more similar as it looks. It should be noted,
that the tokens are only temporary tokens, that should be valid only several
minutes. So the eMail system is not a storage, but a transmission medium. You
also could use SMS or any other scheme that guarantees that only the valid
receiver will get it.

Of course your proposal is superior, but the infrastructure is not available
yet. For web-apps with low security demand, I think the discussed scheme would
be sufficient (since we already have security implications because of password
reset schemes -- and real secure schemes are seldom. In Germany there even
where attacks to two-factor authentifications via mobile of banks ... the
attackers just ordered a second sim-card in the name of the legal user and
intercepted the snail-mail).

~~~
davidkhess
Ah, so the expiration issue is smaller than I thought. Thanks for that info.
Still, it represents a training issue for users and a new framework to be
incorporated into a web app. Those are both barriers to wider adoption.

I agree the security of this solution may be right for certain applications.

Yes, my proposal is an infrastructure play - but I believe it is a more
realistically achievable one than most password alternatives.

~~~
PythonicAlpha
Yes, I also think that it could be achieved. The problem as everywhere is the
adoption. When two or three big companies would stand behind it, it could be
easily implemented and I really would like to see a scheme like that.

There are of course some questions, that also would need to be solved. For
example: What if an other person has access to my computer -- than I still
would need some kind of master-password that had to be remember-able. Also
there must be methods, to transfer my keys to an other computer or to "copy"
for example onto mobile devices.

The example of the SIM-card for banking just shows, that the "big security" is
really a hard problem. Two-factor is one idea, but it is always a game where
the attackers are hunting the defenders (or vice versa).

~~~
davidkhess
Re: shared device use, yes, you would continue to do password management best
practices (fingerprint scans, master passwords, etc.).

I see the transferability as an export/import format issue. W3C, browser
vendors and password managers need to agree on a format for keychain
export/import.

Note that this technique could still be used in conjunction with multi-factor
auth. Since it is just an evolution of passwords, those type of mechanisms are
still relevant and compatible (though, eliminating knowledge factors should
reduce need for a second factor).

------
amino
Oculus have been doing something similar with their order tracking for quite a
while now.

------
ilitirit
This is (partially) only as secure as your email provider's authentication
system.

------
mbrain
What to do with projects those have both web and mobile apps?

~~~
esolyt
All your mobile devices probably already have access to your primary email
account.

~~~
ianburrell
But the mobile app doesn't. Which means you are making the user go from app to
email to browser and back to app. If you are lucky, the login link can open in
app. If not, you need to transfer login from browser to app.

------
peterwwillis
(edited down for size)

Problem with this system: it requires input on a single device (the computer),
removes an out-of-band authentication option (password), and pushes the
requirement for authentication down the stack to a system without a secure
connection (e-mail, SMS).

In this new system, the password becomes an optional secondary authenticator.
Your primary authenticator is now moved to some pre-authenticated service,
such as your e-mail (which you have already logged into, presumably with a
password) or SMS messaging (which you have already logged into, presumably
with a swipe or pin on your phone). On top of that, neither of these uses a
secured connection, so MITM/interception are trivial, to say nothing of
phishing+CSRF.

One of the major flaws with existing out-of-band authentication access is that
we assume the user only has one form of input: the computer. If the computer
gets hacked [via malware] the user cannot protect themselves. But the future
is here, and we carry [networked] computers in our pockets! Turns out the most
secure way we can authenticate is via two separate networks and two separate
computers using two secured connections. Example:

    
    
      Step 1. User requests to login to HTTPS Site A.
      Step 2a. Site A prompts User for a password.
      Step 2b. Site A sends an SMS to User with an HTTPS link to click.
      Step 3a. User enters password on site.
      Step 3b. User clicks link on SMS in mobile device.
      Step 4a. Site authenticates password.
      Step 4b. Mobile site reads cookie on User's mobile browser.
      Step 5. User is authenticated; both mobile device and computer have access to site.
    

Here you have two different authentication factors on two independent devices
which are combined to authenticate the user. The attackers now have to steal a
cookie or auth token from two separate devices at once. This is of course
completely plausible, but is a much more expensive attack than any currently
implemented. Best of all, the user doesn't have to remember the password if
they use their browser's password manager or a cookie is stored locally.

It would be trivial to add this dual-auth method to their existing system, so
hopefully they implement that instead of throwing the baby out with the bath
water.

For what it's worth, of course, here's an attack that could compromise that
system. Attacker shows user a phishing password prompt page that uses a
browser hack to steal a cookie. Attacker sends an SMS to the user (assuming
they found the user's phone number) with a link to another site which also
exploits the mobile browser to steal that cookie. Now the attacker has the two
cookies and can log in, assuming the site does not use an Authentication
Manager that detects attackers who steal credentials (only large-dollar sites
use these).

