[OpenID] Mis-using generation identifiers to request SSLtreatment

[Drummond Reed]

I have to agree with Andrew on this. The attack he outlines is one way that
starting with a weak http: URI and trying to "step up" to a stronger https:
URI does not get you the protection of starting and staying within https.

 

I don't have a solution to this issue with http URIs. I will note, however,
that XRIs can automatically use https 100% of the time without users having
to know/do anything.

 

=Drummond 

 

  _____  

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Andrew Arnott
Sent: Sunday, November 02, 2008 10:12 PM
To: Martin Atkins
Cc: general at openid.net
Subject: Re: [OpenID] Mis-using generation identifiers to request
SSLtreatment

 

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/82f720cc/attachment-0002.htm>