launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

> We support KDE via Kubuntu and many Ubuntu developers use it;
> gnome-keyring seems rather specific; can we, as Sidnei suggests, use
> an abstraction layer to provide the benefits [currently only
> encryption?] to those environments too?

This is an excellent idea. I've asked Benji to implement this before
landing his launchpadlib branch.

> We *have* had credentials for key members of Ubuntu compromised in the
> past (through them pasting a openid cookie IIRC) and that route
> remains unaltered. The change that you're doing makes oauth roughly
> the same as openid cookies.

I can see what you're talking about but I'm not sure what exactly
happens in these incidents. (Part of this is likely my lack of
knowledge about OpenID.)  Can you give more details about this
compromise, or point me to someone who can?  Did someone paste a URL
containing their OpenID secret, or the cookie itself? (Like from an
HTTP dump?)

I'm curious about this because I hadn't really considered _accidental_
security breaches, even though those are the most common kind. I'm
going to give this some thought and see if there are any easy
countermeasures. This list may not be the best place to have this
discussion, but I'd like to offer three preliminary ideas:

1. My change doesn't change our use of OAuth very much. Once it hits
   the network, a DESKTOP_INTEGRATION token is exactly the same as a
   WRITE_PRIVATE token. The procedure for authorizing a token is
   exactly the same as before; it just happens less often. And I don't
   think the distinction between a file on disk and a key in the GNOME
   keyring is relevant here. So if we have a problem, I don't think
   it's a _new_ problem.

2. I have no idea if you can revoke an OpenID cookie, but it's easy to
   revoke an OAuth token if you accidentally publicize the
   secret. It's also easy to get a new token to replace the one you
   revoked.

3. We never put a token secret into a URL. We frequently put a token
   *key* into a URL, but it's the key to a *request* token. The main
   attack here is that Alice intercepts Bob's +authorize-request URL,
   waits for him to sign the request token, and then tries to exchange
   the request token for the signed access token, before Bob gets
   around to doing the exchange himself. This is a real attack, but
   it's not new.

> Perhaps we should set a vision for what we'd like to achieve here:
> Single sign on (web, casual apps, daemons like Ubuntu One), persistent
> credentials (if the user wants - I would!), easy authorisation of new
> apps (single clicky clicky dialog, in some trusted computing base),
> timeouts (defaulting on for high privilege levels), powerful per-app
> controls (like the openid prompt which says what is being disclosed),
> and only one protocol needed (rather than two, managed separately but
> with equivalent issues).

Let's do this, but let's keep the vision classified in tiers or
something. "Persistent credentials" is trivial. "Only one protocol"
may not be 100% possible, but the possible part is worth
doing. "Trusted computing base" seems like a project we could devote
an entire Ubuntu release to, assuming it's possible at all.

If we're aiming so high that "trusted computing base" is actually on
the table, then I'll stop shooting down ideas that assume it, and
start putting them in the appropriate tier.

Leonard

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