OpenID in desktop apps

jDavid jdavid.net at gmail.com
Sun Feb 8 02:17:32 UTC 2009


I also do not like the trend, but really our approach is flawed, as we
can not restrict the use cases at the api level that do not provide
sufficient trust to the user.

Facebook also does not user the HTTPs protocol to deliver the login
page, but rather just submits to an https endpoint.  the flaw here is
that a man in the middle attack could fake the facebook page and use
the facebook html via a proxy, and replace the post location with one
of their own choosing so by the time the user hits submit, the email
and password are already sent off to the evil.com website.

What we are doing is defining a look and feel to trust, and any
phisher that mocks that flow will have the trust of the user, so when
the phisher presents a login pattern requiring a user name/ pass, they
will get a certain percentage of user name passwords.

As for the browsers, I thought it would be great if you could somehow
see the lockicon, or certificate when mousing over iFrames.  However,
this requires browsers to change.  Browsers forcing the appearance  of
an address bar for https connections seems reasonable too, but again
requiring a change to the browser.

The best information the OP has is the last piece of private data
posted to their site.

When we were working on socialhelix, we wanted a secure way for
widgets to talk to a server.  From what we found, if we put a non
expiring cookie on the userside via https, the cookie would never be
transmitted in the wild, so essentially it was a true secret.  Then we
could use that cookie to request a general token that could be used on
non https connections.  Using flash makes this easy to do the
crossdomain access, however javascript is less direct, and is less
stable in its approach to make crossdomain calls (a browser patch
could destroy the flow).

I would love to hear other ideas.

On Sat, Feb 7, 2009 at 5:33 PM, Chris Messina <chris.messina at gmail.com> wrote:
> I highly recommend that all those whom I cc'd join the user-experience list
> at OpenID if you haven't already:
> http://openid.net/mailman/listinfo/user-experience
>
> I wanted to point out a disturbing but insightful trend that I've seen in
> apps, both on the Mac and iPhone lately... essentially embedding a WebKit
> view inside the app for doing delegated authentication. Example:
> http://www.flickr.com/photos/factoryjoe/3260710115/
>
> Without the URL bar (presuming that the URL bar hasn't been tampered with),
> it's impossible to know who is hosting this page. Facebook is also
> none-the-wiser about whether this experience is taking place from within the
> browser or within some custom app. I also don't see how this can be stopped.
> I'd like to hear your thoughts about this, given our desire to push the
> popup experience forward, mandating, I presume, visibility of the URL bar in
> these flows.
> Chris
> --
> Chris Messina
> Citizen-Participant &
>  Open Web Advocate-at-Large
>
> factoryjoe.com # diso-project.org
> citizenagency.com # vidoop.com
> This email is:   [X] bloggable    [ ] ask first   [ ] private
>
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>
>



-- 
-- 
Justin Kruger -- Sr. Software Engineer - MySpace MDP
http://jDavid.net
jDavid.net at gmail.com

"A dreamer is one who can only find his way by moonlight, and his
punishment is that he sees the dawn before the rest of the world." -
  --  Oscar Wilde



More information about the user-experience mailing list