> 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
