Capability urls for accounts

[David Bruant]

Hi,


For context, MDN is removing the Persona login option [1], leaving MDN
in a somewhat uncomfortable situation that logging to MDN now has to go
through github which generates a bit of frustration to some people.


I'd like to discuss here an option to get out of the github-auth-only
situation.

One solution could be to use capability urls [2] as a form of login. The
way it would work would be that someone who creates an account provides
an email address (as they do today) and on account creation, the user
would receive a confirmation email (as it does today, I imagine? It's
been a long time I created my account). This email would contain the
capability url for account sign in. Something along the lines of:

------------------

Thank you for creating an account, David Bruant!


If you want to login and start editing MDN, please go to:

https://developer.mozilla.org/login?cap=86700D44NND4KNF5O5NFP5K


If you received this email by mistake, blablabla...

------------------


The backend knows that 86700D44NND4KNF5O5NFP5K is associated with
brua...@gmail.com, so it knows which account this associates to.

What to do with this URL can be open, but one idea would be to login the
user (create cookies, a Django session or whatever you're doing today)
and then 302 redirect to https://developer.mozilla.org/ (but now there
are cookies and stuff, so it's all good).


# Benefits


* Easy (?) to implement

* The URL can be bookmarked (!), so logging in to MDN takes literally
one click

* Independance from identity providers (which can be seen as a downside)

* Creating an account on MDN only requires an email.


# Security properties


* The capability URL is meant to be unguessable. If the random part is
long enough it's as good as a random password [3]

Securing the MDN user account boils down to securing the email account
(which the user already has to do in both the persona and github case),
so this solution is not asking more of them.

* People do not choose a password (so they avoid the password reuse
issue and dictionary attacks)

* People can go to MDN and ask for another capability URL. It revokes
the previous one if it's been compromised or lost.


Of course, this email is only intended to be the beginning of a
discussion. I'm happy to answer any question or concern.


David


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1273028

[2] https://w3ctag.github.io/capability-urls/

[3] https://twitter.com/jessysaurusrex/status/766340481101934592

[John Whitlock]

David,

Thank you for the thoughtful post. I enjoyed reading the W3C document,
which closely mirrors my own thoughts on the pluses and minuses of this
technique.

I don't think capability URLs are a good authentication mechanism for MDN.
I wrote a very long post explaining why, but I think I can summarize it
without boring everyone.

Capability URLs are a good match for task-specific authentication, like
password resets, and metered, shared access, like an API URL for a team.
They are not a good match for reputation-based authentication system.

MDN authentication has two purposes:
1) Collaboratively edit MDN content
2) Access MDN administrative functions

Collaborative editing requires trust. We watch new edits closely, to
determine if a user is abusive or just misguided, and quickly remove
access. As a user proves themselves, they are watched less closely, and
are given more editing permissions. Capability URLs make it too easy for
bad actors to establish new accounts, and increase the spam mitigation
effort on MDN, distracting from adding features and content. "Easy account
setup" is not a feature for MDN.

Because they auth mechanism is a URL, it appears in browser history, as the
referrer for the next page, in user emails, in IRC chat logs, in server
logs, and in the database. This increases the number of places that an
attacker can acquire a capability URL. Since they are easier to steal, they
can more easily turn a good account into a bad one, which can be harder to
detect and stop.

There is a suite of other pieces needed to secure a capability URL scheme.
This includes a cryptographically strong random number generator, detection
of multiple requests from the same IP address, detection of a distributed
attack from a botnet, extra security around access to the database and
server logs, a "URL reset" mechanism, an email account that is trusted by
email providers for delivering the URLs, a strong "unsubscribe" policy that
is accepted by the providers, challenge questions, 2-factor auth support,
and others. These are similar to the pieces in a secure username+password
setup, which is why that is not being considered either.

In a lot of ways, Persona is the "version 5.x" of a capability URL scheme.
All the authentication happens in one place, so you can concentrate your
resources to make that one place secure, and detect and block the abuse.
An email is sent to confirm an account as needed or to reset a password,
but the browser is leveraged to remember the login. The user logs into one
site they trust, and then the other sites (like MDN) just trust
login.persona.org. Optionally, email providers can sign up for advanced
login capabilities, like substituting Google login, with 2 factor auth and
abuse detection.

And, Persona didn't catch on, and is now cancelled. Authentication is hard.

https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
https://wiki.mozilla.org/Identity/Persona_AAR

So, what do we get with GitHub login?

1) We delegate all the security stuff to GitHub. They mess with SSL
certificates, abuse detection, IP blocking, etc. etc. They need it for
their business to be successful. And GitHub is a business, so they can
justify paying good people to get it right.
2) They offer stronger login than just username and password. I have 2
factor authentication enabled on GitHub, and I recommend everyone else does
too.
3) When a user signs up with GitHub, we get to see their history on the
site. This is a huge benefit on the code side. For example, this user
just added some translations to the MDN UI in Frisian:

https://github.com/mozilla/kuma/commit/26a339974241355e53937dead92b27
ac503c3f19

I don't know Frisian. Did he just add obscenities to the site? Do I need
to plug them into Google Translate and figure it out? Well, I feel a
little more confident, because he has a long history of translating other
Mozilla properties:

https://github.com/Fjoerfoks?tab=activity

When a user with a GitHub history shows up for a first edit on MDN, I can
see that she's probably making a good change with good intentions. Does
this person even know CSS? Well, if her GitHub account includes a demos of
some CSS animation experiments, they may know a thing or two.

Finally, as we formalize some of the content structures, such as browser
compatibility and demos, we're increasingly leaning on GitHub for storage
and collaboration. This effort will only increase in the future, so it's a
natural fit to have a strong link between activity on GitHub and activity
on MDN.

I think capability URLs are an interesting idea, and useful for several web
authentication scenarios. However, as a site matures, it needs to switch to
stronger authentication, and I think it would be a step backwards for MDN
profiles. If we add an alternate, user facing login method, we're more
likely to pick another delegated authentication provider, and probably from
this list:

http://django-allauth.readthedocs.io/en/latest/

Thanks for your feedback, and I hope you continue contributing after adding
GitHub auth to your MDN profile.

John

> _______________________________________________
> dev-mdn mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdn
>

[David Bruant]

Hi John,

Thanks a lot for taking the time for this detailed answer. I guess I'm
coming to agreeing with what you're saying, so I won't answer on the
overall topic.

However, there is a point which deserves a response.

Le 19/08/2016 à 18:03, John Whitlock a écrit :
> Because they auth mechanism is a URL, it appears in browser history,

> as the referrer for the next page (...)
There are features that can be leveraged now to prevent this.

https://html.spec.whatwg.org/multipage/semantics.html#meta-referrer
https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-same-origin
In a nutshell, <meta name="referrer" value="same-origin"> will make that
a webpage only sends the referrer to same-origin pages and does not send
a Referer HTTP header if going to a cross-origin website.
This is already implemented in Firefox and Chrome


Solving a different problem (preventing CSRF altogether), there is an
upcoming feature called "same-site cookies" to keep an eye on.
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00
In a nutshell, it can be used by a website to tell the browser "only
send the cookies in the context of same-origin requests".
Implemented in Chrome, not yet in Firefox.

David

[gilbertt...@gmail.com]