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
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
