This whole key thingy however has a fundamental privacy problem esp in the case of "one key per install" - it effectively resembles the UUID that Intel tried to put in their CPUs a long time ago. And this UUID stuff was shot down for very good reasons.
A central server that issues keys per install defeats one of the most important goals of statusnet - distributed architecture. I know I am radical and paranoid, so don't take me too serious, I just want to raise awareness that trust should be controlled by the user, not by the server. Trust delegation is one of the most important values in a federated, distributed world we aim for. But trust delegation must be controlled by the user. A system that forces the user to hand over trust delegation to the sever creates an uncomfortable situation. Again, just my .02 on a very radical level. Not aiming at a flamewar, but looking for good arguments to make sure the user controls his data. Jan ----- Original Message ----- From: statusnet-dev-boun...@lists.status.net <statusnet-dev-boun...@lists.status.net> To: StatusNet-dev@lists.status.net <StatusNet-dev@lists.status.net> Sent: Wed Sep 08 17:32:08 2010 Subject: Re: [StatusNet-dev] OAuth, open source, and key registration On 9/8/10 11:45 AM, Evan Prodromou wrote: > On Wed, 2010-09-08 at 11:09 -0700, Brion Vibber wrote: >> Clients connecting with a dummy key would be given the same level of >> trust as clients connecting with HTTP basic auth: we know they're acting >> on behalf of the user since they have his/her credentials, but we can't >> know for sure what software they are -- so eg the 'source' parameter >> saying 'Mustard' or 'StatusNet Mobile' could be faked, so we know we >> can't reliably use it to throttle or limit particular clients. >> >> Any thoughts? > > I'm dubious; seems the opportunity for phishing is really high. > I wonder if using OAuth 2.0, or a dynamic-key generation system like CCK > would make more sense. > > http://developer.yahoo.com/oauth/guide/create-consumer-key-guide.html A malicious client doesn't even need a valid key for phishing, it just needs to point you at something that you think is your login page, then steal your credentials directly. :) A trained user might be able to verify that they're on the right login & OAuth confirmation page, but without policing app registrations, malicious apps can simply register themselves to look like a legit app on the confirmation screen. That won't expose the credentials to the malicious app, but it will let the malicious app gain whatever access the user is (mistakenly) allowing it. Dynamic key generation doesn't really help for that case, since there's still no way to distinguish between a key request from a legit app and a key request from a malicious app. One thing that dynamic key generation would help with though is helping to uniquely identify a particular instance of a multi-user web application. So if there were, say, an open-source web app that's a StatusNet client, a particular installation of that app could register itself against a particular upstream host, and from then on an unexpected change in keys would be suspicious. (Bonus points if dynamic provisioning of keys for web apps has some way to verify the requesting site!) I think if we do want to apply any trust based on app keys, we need to have a couple separate dimensions. Right now we distinguish between 'web' and 'desktop' apps, where web apps send auth tokens back on a return URL and desktop apps send back a PIN identifier which the user has to type into the app so it can retrieve the final credentials. Mobile apps often use the 'web' mode with a custom URL handler, so the auth steps in the browser can relaunch the app, skipping the manual PIN step -- so we need to make sure we can still use that mode on an app that's not fully trusted as keeping its key secure! So: * trust the key to remain secure / assume key is being distributed * can verify the URLs provided with the registration / treat URLs as untrusted * app can use URL token return with this key / app must use PIN mode And maybe an extra level: * site admins trust this app / site admins never heard of it Not sure how much of this is needed on what levels, or how to present it well without getting confusing though. :) But at least... if we've got cases where we assume keys aren't kept secure and none of the data is trustable, I think we're just as good without a registration as we are with a dynamic registration. -- brion _______________________________________________ StatusNet-dev mailing list StatusNet-dev@lists.status.net http://lists.status.net/mailman/listinfo/statusnet-dev _______________________________________________ StatusNet-dev mailing list StatusNet-dev@lists.status.net http://lists.status.net/mailman/listinfo/statusnet-dev
