

Identify with email: no need for passwords - sgustard
https://medium.com/p/d6509aa3c60b

======
quanticle
Isn't this _exactly_ what Mozilla Persona [1] does?

EDIT: In fact, Persona goes one better. Persona has the browser act as an
intermediary between your e-mail provider and the site that you're logging in
to, so that the e-mail provider doesn't get to see the source of the
authentication request, and the site that you're authenticating with doesn't
get any further details beyond your e-mail address.

[1] [http://www.mozilla.org/en-US/persona/](http://www.mozilla.org/en-
US/persona/)

~~~
benatkin
> the site that you're authenticating with doesn't get any further details
> beyond your e-mail address

But Mozilla's servers (or the email provider, but I don't expect to see any
significant uptake of this feature) get information in the HTTP requests,
whether they like it or not, and they're based in the US.

~~~
fmarier
Right now, you're right and that's because of the temporary centralized
components:

1\. JavaScript shim 2\. include.js 3\. Centralized verifier 4\. Fallback
identity provider

However, we've designed the protocol so that all of these pieces (necessary to
bootstrap the system) will go away over time.

#1 will go away once we have native support in the browser (some of our
developers have starting working on this). #2 will go away once we make
include.js self-hostable, which we are definitely planning to do. #3 will no
longer be needed once sites can use local verification libraries, which we
have started writing. #4 can already be avoided if you put up your own
identity provider (several people have done so).

------
crazygringo
I've implemented a site before that did exactly that, because logins would be
very infrequent so users were probably just forget a password anyway. It
worked great.

BUT, it would drive me nuts if I had to do that every time I logged into my
bank, for example, because sometimes e-mails take 1-2 min to arrive, very
occasionally even half an hour. They get queued up somewhere along the way,
who knows -- maybe the spam filter's being overloaded. Sometimes your
organization's e-mail simply goes down. Sometimes your webmail goes down.
Heck, sometimes your e-mail gets inadvertently disabled.

If it were instantaneous, and your e-mail account always worked perfectly,
then it would be great. But the way things are set up right now... this isn't
a viable option for a lot of sites. And it's certainly not going to replace
your e-mail password ;)

~~~
bradleyland
> "sometimes e-mails take 1-2 min to arrive, very occasionally even half an
> hour"

That's because SMTP (the protocol that moves email around) doesn't guarantee
delivery in any specific time period. Many MTAs (message transfer agents) are
configured by default use retry intervals measured in minutes, not seconds.

Relying on email for authentication means asking your users to wait minutes,
not seconds, and asking users to wait minutes to get logged in to your website
is horrible usability.

~~~
__--__
Isn't this also horribly insecure? Unless it's encrypted (ha. ha.) anybody can
intercept the email and get access to your account.

------
brianwillis
_And believe it or not, some people do not use, like, or trust Facebook or
Twitter._

Yup, I'm one of those people.

I don't use Facebook, and it's unreasonable to expect me to sign up for a
Facebook account so that I can use your service.

I do use Twitter, but I'd rather not share my account details (even just the
username) with someone I've just met.

I've always thought that being able to explore the web of information out
there about me was kind of creepy, and I'm not about to make it easier for
someone to do by creating connections between the accounts I have with
disparate service providers. I like when my data is siloed, and only shared on
my terms, with my explicit consent.

~~~
ashray
Not only that but facebook may block your account at a whim. Happened to me
once for posting 'explicit pictures'. The picture was not even explicit,
apparently something tripped their automatic 'skin detection system'. But the
result ? I couldn't log into any 'facebook connected' sites.

Better to create separate accounts on each site and minimize dependencies.
Also, if you lose your facebook password, it's just your facebook account
that'll potentially get affected.

------
refrigerator
I'm not a fan of this idea:

From a user experience point of view, it's much more effort (at least 3 clicks
more) to have to open an email client, open an email, and click a link, as
opposed to just entering a password.

Also as airlinenut mentioned, it would allow others to send you an annoying
email just by entering your email address, and any methods to prevent this
(captcha etc) will just make it even harder for the user.

~~~
greensand
People sending you annoying emails with this method is not really an issue as
anyone that knows your email can (and does) find easy ways to annoy you (spam,
phishing, chain letters etc.). I do agree however that the user experience is
a deal breaker. I'd rather enter a password than open a client and wait for an
email to arrive just so I can log in.

------
lkbm
> They now need not implement any cryptography.

This sentence implies to me that under the current system, sites need
cryptography, because sending login information in plaintext is not secure
enough.

...and that the solution is to use email, because we already treat it as if
it's secure.

...even though it sends the data in plaintext.

Okay, so most end-users probably accesses their email via https these days,
but it's a (potentially) long journey from the website to the email provider's
server.

Is any of that server-to-server journey ever encrypted? I'm no expert, but my
impression has always been that it's not.

~~~
prutschman
> Is any of that server-to-server journey ever encrypted?

It can be, thanks to RFC 3207 (STARTTLS).

However, unless you configure your sending MTA to require TLS (and in turn
give up the ability to send email to a large swath of the internet) you have
no protection against a MITM adversary hiding the recipient's advertisement of
STARTTLS.

------
swanson
I tried a similar approach on
[https://www.moraleapp.com](https://www.moraleapp.com) with mixed results. It
makes sense for a manager/boss to have an account, but I didn't want to have
every team member sign up for yet another service. So each email sent out gets
a randomly generated token that allows the recipient to "log in" (all
responses are anonymous, each sent email has a token - not each email
address). I think the idea is really great and helps with adoption within a
team, but it has also led to some confusion because there is also a
traditional Login page.

My take-away is that it is probably better to go all-in on one approach (all
email-based or regular logins) than a half measure. It is kind of interesting
because it seems to cause trouble for users that are semi-technical; the ones
that know how a username/login works in general, but are thrown for a loop
with this whole "email is how you login to our special app!" thing. Super
technical users understand and super newbies don't really seem to notice, but
those middle ground users are a bit confused.

------
parsnips
How is this not identical to sending the user password in the clear via email?

~~~
eberfreitas
I guess it is as good as sending an email with a link to reset a password. In
theory, the link that gives you access to your account couldn't be used after
X minutes and could be use only once, making it useless for future attempts.

------
Kequc
Allow the user to sign in with their password, if they cannot remember their
password or would rather sign in with their email then allow them to receive
an email containing a token that logs them in. From their account settings
they can change their password.

This is already how most websites work isn't it?

~~~
zzzcpan
Kind of, the only thing missing is proper user experience. Like having an
input for e-mail and another button right on the login form.

------
yuliyp
Don't most sites let you do this already? It's usually behind a button labeled
"forgot password"

------
brianmcconnell
Since virtually every service has a 'forgot password' option, all the OP is
suggesting is to formalize this as a default login process for second tier
services that are too much of a bother to keep track of.

The net positive, if this were implemented across the board, is that users
would focus their efforts on securing a few high value accounts, versus
reusing the same password across dozens of low value accounts (chain, meet
weakest link).

------
eksith
This is actually the same method we use for logins, when the cookie is absent
or expired, at a forum I'm currently running. They get sent a unique login
token that expires in a few minutes (or is force expired if they request a
resend of the login token) and get presented a CAPTCHA after following the
link if they've already tried a few times.

Login email delay increases exponentially with each request.

------
duck
I've thought about this exact thing. Couple additional ideas - I would make it
email or SMS and two, you could reduce the number of steps by using gmail
actions -
[https://developers.google.com/gmail/actions/actions/actions-...](https://developers.google.com/gmail/actions/actions/actions-
overview#go-to_actions)

------
ripvanwinkle
This doesn't change much does it.

You could have one email account in which case it becomes the single point of
failure / attack and you are only as secure as that email provider.

Or you have multiple email accounts in which case you have multiple email
account passwords to remember manage. You might as well have multiple site
passwords

------
daave
> It would tremendously simplify for services. They now need not implement any
> cryptography.

Uhh.. I sure hope the cookie tokens are not stored directly on the server-
side, but rather verified against a (cryptographic) hash of same. These
credentials are as valuable to an attacker as a password (albeit relatively
short-lived).

------
capex
Sometimes there is a significant delay in Gmail sending new emails to a
desktop client. That can be a dealbreaker for this.

------
smackfu
Besides the problems with email delivery speeds, which tend to make this
frustrating in reality, this also has the problem of being different. And
users don't really want to deal with different just to log in to your site.
They know userid + password, and there is no learning curve.

------
alexsmolen
I built a Rails engine that does this, see
[https://github.com/alsmola/nopassword](https://github.com/alsmola/nopassword)
and [https://nopassword.alexsmolen.com](https://nopassword.alexsmolen.com)

------
samweinberg
I don't know if I would trust this as the sole authentication method for any
of my online accounts, but this could be useful as a multi-factor
authentication method instead.

------
MaxGabriel
If you wanted to later make an iOS or android app, wouldn't you need a
password since you wouldn't have the cookies?

------
fakeanon
E.g.: [http://hi-games.net/login.cgi](http://hi-games.net/login.cgi)

------
captaincrunch
This is essentially just two-factor using email... give me your phone and I
can steal anything I need.

~~~
aes
Assuming the phone isn't locked.

A combination with email confirmation plus two-step verification like Google
Authenticator could work as well.

~~~
parsnips
If the attacker has the phone, the second factor (typically sms) won't work
very well.

------
vesnalorem
[http://pixelpin.co.uk/](http://pixelpin.co.uk/) ?

~~~
drill_sarge
thats basically the same what windows 8 does. curious that microsoft didn't
patent this in some way?

~~~
vesnalorem
PixelPin's mission is to rid the world of passwords for ever and replace them
with an engaging and easy to use picture based system.

They provide businesses and organisations an authentication service for their
customers. The service is enabled for all web applications, and can be
accessed from any user device. PixelPin replaces the current password solution
which is expensive to manage and full of vulnerabilities with a very user
friendly and memorable solution that uses personal pictures from the users own
device as a means of authentication. The service is very secure and maintains
the users privacy. Once a user has completed the simple process to set up a
PixelPin account, they can then login to any PixelPin enabled web service.

Info and the Dev pages at
[https://login.pixelpin.co.uk/Developer/Index.aspx](https://login.pixelpin.co.uk/Developer/Index.aspx)
for tech integration info. Integration can be achieved in 2 to 4 hours.

By the way Windows 8 can not do this, but PixelPin can replace Windows 7 and 8
login

------
zeckalpha
Emails are postcards.

------
airlinenut
One downside (not security-related) would be the need for captchas to prevent
people from being robo-spammed by repeated entry of email address into various
forms. Alternatively you could rate-limit emails, I suppose.

