[OpenID] Mis-using generation identifiers to request SSL treatment

[Andrew Arnott]

Interesting observation, Martin.  You make a good point.
However, it is insecure because it is then susceptible to phishing.  Imagine
a scenario where I usually log in simply as "blog.nerdbank.net", which we'll
assume redirects to https://blog.nerdbank.net at the OP.

   1. Attacker using DNS poisoning to fool the RP into resolving "
   blog.nerdbank.net" to the attacker's server.
   2. I begin to log into the compromised RP.
   3. I am redirected to the attacker's OP, which is designed to look like
   mine.  I am asked for my login credentials, and I use a password (bad, I
   know, but go with me on this scenario).
   4. I give my password and the site lies to me and says I've logged in.
    It redirects me to the RP, where my account... isn't there, since as you
   say Martin, it's a different account at the RP.
   5. Now the attacker has my real OP's login credentials and can now log in
   as me using my real account at the compromised RP, even after the RP
   recovers from the DNS poisoning.

So you see, using insecure HTTP at all during identifier discovery is a bad
thing.  Yes, it can be mitigated by using non-phishable credentials like
Cardspace or X.509, but since most users don't use that yet, using HTTPS
identifiers that do not rely on redirects from HTTP identifiers is the only
secure way to go.

On Sun, Nov 2, 2008 at 9:57 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> SitG Admin wrote:
> >
> > Indeed. Yet how well have we done at communicating this to users? How
> > consistently do they enter their secure URI instead of omitting the
> > prefix entirely? Solutions have been suggested, if I'm not mistaken,
> > such as detecting incoming requests from RP's to the HTTP page and
> > redirecting them to the HTTPS version, or having OpenID headers stating
> > that only the HTTPS version should be used for OpenID - but what if the
> > RP contacts a hostile server because its initial request was not secure?
> >
>
> Having a http: URL redirect to an https: URL is secure even if the http:
> URL is compromised, because the redirect "canonicalizes" the claimed
> identity to the https: URL.
>
> While an attacker can in theory compromise the http: URL and make it
> redirect somewhere else or not redirect at all, since the user's
> accounts are tied to the https: URL they don't gain access to these
> accounts.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081102/c6c14e88/attachment-0002.htm>