launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

> Agree.  My argument about client-side security is that there is little
> point forcing the user to do an interaction through a web browser
> rather than through any other client-side program.

I have completely capitulated on this point. Even so, once Launchpad
becomes an OpenID consumer, a web browser will be the only tool general
enough to complete the Launchpad authentication process, since that
process might involve a redirect to Livejournal or Facebook and a trip
through whatever HTML forms they throw at you.

With the desktop credential-granting service, you'll go through the web
browser only once, to create a GRANT_PERMISSIONS OAuth token for the
credential-granting application itself.

The credential-granting application then uses the GRANT_PERMISSIONS
token to grant additional tokens _using the web service itself_, without
going through the Launchpad authentication process.

> > 2. If we really consider scenario 4 and scenario 1 equally insecure, we
> > might as well go for the superior usability of scenario 4.
> 
> Sorry, I'm not sure what "API to create a new OAuth token" means.  API
> on the desktop credential-granting service?  I don't think you should
> be able to use a less-privileged token to make a WRITE_SENSITIVE_DATA
> one.

Yes, "API to create a new OAuth token" means a new feature of the
Launchpad web service which will allow the credential-granting service
to create new OAuth tokens without making the end user re-authenticate
with Launchpad. The launchpadlib code would look something like this:

new_token = launchpad.me.oauth_access_tokens.new(
    consumer="consumer", access_level="WRITE_PRIVATE")

This action requires the GRANT_PERMISSIONS access level.
GRANT_PERMISSIONS is, by definition, the most privileged access level.
The only application that should ever have GRANT_PERMISSIONS is the
desktop credential-granting service.

I like the idea of making WRITE_SENSITIVE_DATA tokens expire so that old
tokens found on backups or abandoned drives won't work anymore. But I
don't think that will help, because typically the GRANT_PERMISSIONS
token will still be available, and an attacker can just use it to create
a new WRITE_SENSITIVE_DATA token.

The two solutions to this problem:

1. Make the GRANT_PERMISSIONS token also expire after a while.
2. Prohibit the GRANT_PERMISSIONS token from creating
WRITE_SENSITIVE_DATA tokens, even though it can create other kinds of
tokens.

Both of these solutions require opening the web browser more often, at
seemingly random intervals. Not, at this point because the web browser
is more trustworthy than the permission-granting app, but because the
web browser is the one that can negotiate a redirect to a Facebook
login.

Leonard

Attachment: signature.asc
Description: This is a digitally signed message part