OpenID in desktop apps

[Chris Messina]

On Mon, Feb 9, 2009 at 8:56 AM, Christopher St John <ckstjohn at gmail.com>wrote:

> On Mon, Feb 9, 2009 at 5:42 AM, Paul Walker <pwalker at myspace.com> wrote:
> >
> > Why should we not further the expectations of downloaded/installed apps
> when
> > it comes to security no matter the platform?
> >
>
> But nobody has come up with a way to do that. I'm arguing
> that it's currently impossible. (The suggestions so far provide
> only the illusion of security because they can trivially be
> spoofed by evil apps)


I think the take-away point here is that, if a desktop app has been
compromised, or isn't trustworthy to begin with, not only will the app NOT
do the browser-based popup flow (and users wouldn't like notice the
difference anyway since there's so much inconsistency in interfaces), but if
it has the ability to load a browser view inline, it can essentially sniff
all the traffic sent between the view and the web server, regardless of
whether it shows a 300px tall lock icon.

The reality is we're in Matrix territory here: anything graphical on the
user's computer can, and probably will, at some point, be spoofed to look
more secure than it really is.



> > I don't see a big
> > detriment in the user workflow for even a mobile app that pops up the
> > browser and, after auth, returns to the custom protocol of the app (i.e.
> > facebook:///mygarden_is_now_authed), which communicates back to the app
> the
> > output.
> >
>
> Well, "current thinking" seems to be that the delegated authc/authz
> dance is a detriment, so saying it's not is controversial (and ref
> evidence that even small impediments to usability can significantly
> reduce user acceptance of security enhancements)


I think we need more user testing here.

Certainly interface language can help, and screens like this that raise
awareness without raising alarm might be useful (though people eventually
gloss over when they seem them, like EUL Agreements):

http://flickr.com/photos/factoryjoe/3267114792/


> If the platforms don't have mechanisms that help the users insure
> > the Provider, let's make it so rather than "punting" on the issue.
> >
>
> By "make it so" I'm assuming you mean lobby the people in charge
> of desktop and mobile devices to add new security mechanisms to
> their operating systems? I might buy that, actually. But it doesn't
> help in the short term.
>
> If you mean "pretend that forcing use of a browser really adds some
> sort of security even though we know it doesn't" then I'd disagree
> strongly.
>

I think that the increasingly reliance on security-through-browser-popups is
creating a pretty juicy target (not that we didn't know that already, but
still).

One argument that I use in favor of OpenID and popping out of desktop apps
for doing authentication is the use of secondary or alternative
authentication mechanisms, such as SMS PINs, phone confirmation or image
shields (as in the case of Vidoop — where your password literally changes
EVERY TIME you authenticate — making sniffing traffic much less useful).

If you merely use an inline WebView, it's unclear to me whether you are
afforded the ability to use whatever arbitrary authentication mechanism you
might use to in your browser, not to mention inhibiting the user's ability
to use their password manager.

Fortunately 1Password found a way to add itself to most apps that leverage
the WebKit embedded WebView, but I don't think that this is the common case.

If we accept that authentication should eventually move beyond mere
usernames and passwords, I think that it becomes much more obvious why we
should think very hard about popping out of desktop apps and into the
browser (or some context that allows for arbitrary authentication
mechanisms).

Chris

-- 
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090209/c4fa2097/attachment-0002.htm>