Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

OAuth musings

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


lists at nadir-seen-fire

Jul 14, 2012, 1:30 AM

Post #1 of 3 (442 views)
Permalink
OAuth musings

I've been reading over various OAuth related specs and resources.

Some interesting things I learned while reading up:

== Clients cannot be trusted with security ==
As far as SSL/TLS goes, this doesn't provide OAuth with as much security
as one might think.
The whole "SSL is broken" factor aside (You know, all the flaws with
CA's and whatnot; https://www.youtube.com/watch?v=Z7Wl2FW2TcA if you
fell like watching something you might not have).
It looks like app's cannot be trusted with something as /simple/ as
actually verifying that they are talking with the right server (You
know, that MITM protection that was the whole point of OAuth using HTTPS)

3 point on that:
- It seems that the CA root trust setup is not setup by default on
various servers and isn't necessarily very easy to setup
- In php's default settings for ssl:// and https:// the default for
verify_peer "False". In other words, by default https:// connections
made using PHP's native code is no more secure than http://
- App developers often run into cURL throwing an error saying that a ssl
certificate is invalid (because of the first point, no root certs setup
on the machine). When this happens, the reaction of many app developers
is to set verify_peer = False. In fact, there are people that go around
and RECOMMEND this when people ask for help.

If you want some more reading on this topic, these two articles are good:
http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/
http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/

Considering this point on security and the fact that we're not using a
proprietary API and discoverability is eventually going to be a big
thing for us I think that when we implement OAuth we should make use of
signatures mandatory for clients.
We can still allow bearer tokens to be used during development. But
impose extreme rate limits on them to prevent abuse in production (ie:
rate limits more restrictive than api anons currently get).

== We can't always guarantee OAuth authorizations really come from a
client ==
OAuth has the notion of a client_id and a client_secret. There are two
types of clients, "confidential" ones like those on hosted servers, and
"public" ones like client-only web apps, desktop, and mobile apps.
public clients don't get a client_secret because it's impossible to keep
a secret a secret when you hand the entire app over to every user that
wants it. Hence when it comes to public clients you cannot guarantee
that when a user authorized an app the app was actually the app it says
it is.

It means for example. That en.wp could suddenly see bot spam that says
it was made by the anti-vandal tool "Huggle". Because Huggle would be a
public client and the client_id would be public so any random client
could say it's Huggle when a user authorizes it.

This means a few things for us:
- We should make the difference between an edit made by a confidential
client and one made by a public client visible in the UI so editors know
the difference.
- We shouldn't delude ourselves into thinking we can mass-revert based
on client_id when said client is a public client. Instead we should
forget that whole idea and allow admins to see individual authorizations
given by users to public clients and let admins select whole swaths of
them and mass-revert them all at once.
- Under that thought. Since we're going to go to the trouble of building
tools to mass-revert. Perhaps we should take that extra step and make it
a general mass-revert tool. The filtering capability isn't as hard as
the revert handling. Instead of just client_id and authorization we
could let admins mass-revert a selection of users.

== OAuth is a pretty loose protocol ==
OAuth actually leaves a lot undefined:
- The actual verification of a user is completely outside of the scope
of the spec. So it doesn't care whether you make the user login normally
or use some sort of web based device flow within the login system itself
to let web based mobile applications get OAuth grants using the normal
Authorization Code Grant flow but the user themselves get to feel like
they are using a device flow.
- Getting a token and using it are defined separately. Enough that you
could go out-of-spec and write a different method of getting a token. In
fact instead of making you tweak sections of the OAuth protocol as you
would in OAuth 1.0 the OAuth 2 spec has a section on "Extension Grants"
that allow you to specify new methods of getting auth_tokens which you
can use to create a new flow.
- While some application flows are defined by the spec you still have
room to implement new types of flows if you have a use-case for it.
- Discoverability is completely out of scope of the OAuth spec. You have
room to develop your own pattern of discoverability. (And with
signatures you might even be able to come up with a way to make wikis
run over http:// secure enough to use OAuth)

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


niklas.laxstrom at gmail

Jul 14, 2012, 6:09 AM

Post #2 of 3 (386 views)
Permalink
Re: OAuth musings [In reply to]

On 14 July 2012 11:30, Daniel Friesen <lists [at] nadir-seen-fire> wrote:
> I've been reading over various OAuth related specs and resources.
>
> Some interesting things I learned while reading up:

Can we have TL;DR version too? Anything else than "there are many
problems with OAuth"?
-Niklas

--
Niklas Laxström

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Jul 14, 2012, 9:35 AM

Post #3 of 3 (384 views)
Permalink
Re: OAuth musings [In reply to]

On Sat, 14 Jul 2012 06:09:54 -0700, Niklas Laxström
<niklas.laxstrom [at] gmail> wrote:

> On 14 July 2012 11:30, Daniel Friesen <lists [at] nadir-seen-fire> wrote:
>> I've been reading over various OAuth related specs and resources.
>>
>> Some interesting things I learned while reading up:
>
> Can we have TL;DR version too? Anything else than "there are many
> problems with OAuth"?
> -Niklas
>

Ok, TL;DR version:

Facts:
App developers cannot be trusted with security. HTTPS when used by app
developers is regularly no more secure than HTTP. Certificate stacks are
regularly unconfigured. PHP's own default for HTTPS is to let anyone
impersonate a website. And app developers are regularly stupid enough to
disable verify_peer (let anyone impersonate a website) themselves and
RECOMMEND this to other people when they ask for help.

Conclusion:
Considering this point on security and the fact that we're not using a
proprietary API and discoverability is eventually going to be a big
thing for us I think that when we implement OAuth we should make use of
signatures mandatory for clients.
We can still allow bearer tokens to be used during development. But
impose extreme rate limits on them to prevent abuse in production (ie:
rate limits more restrictive than api anons currently get).

Facts:
We're going to have people using 'public' OAuth clients. We cannot trust
that aythorizations made to public clients really come from that client.

Conclusion:
We should ditch the idea of mass-revert by OAuth client_id for public
clients. Instead we should take the extra step to make our mass-revert
tool work as a general mass-revert tool. And we should give admins the
ability to select large swaths of individual authorizations to a public
app (instead of the whole client_id) and let the admin mass-revert all the
ones they selected at once. We should also let users see the difference
between a confidential and a public client inside the UI.

Last musing:
OAuth is quite loose. We have a lot of room to implement our own custom
flows, apis, etc... Two ideas I find really interesting:
- Including a sort of web based device flow into the login page when you
are doing an OAuth authorization. This would mean that if you're using a
web app on your mobile device when you are sent to MediaWiki's login page
you'll have the option of doing a device authorization instead of logging
in with your password even though the web app probably will have only
implemented the normal Authorization Code Grant flow.
- Discoverability is completely undefined by OAuth. I think we can
implement a discoverabiliy + convergence like trick + signatures to make
it possible to use OAuth over wikis that only use http:// secure enough to
use.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.