So requests with no referrer or a referrer that is not related to the
realm are the most problematic.
If a OP's choice is between generating an error to the user for all
checkid_imediates or:
1 allowing them if the user is authenticated to the OP and the RP
passes discovery.
2 allowing them if the referrer matches the retun_to
3 Showing the user a waning message in other cases such as "A site
xyz.com has attempted to authenticate you as https://
ve7jtb.yahoo.com. You are not logged in to your Yahoo account.
Please click here if you wish to return to xyz.com"
I think picking out the likely malicious requests and displaying a
warning to the user in those cases is likely the best short term
option for an OP that is concerned about this.
I don't think it warrants removing checkid_imediate.
Dealing with signed requests will take some significant changes. I
can't say if the benefits outweigh the increased complexity.
There are two separate but related areas that need to be considered.
1. Signing a request so that it cannot be tampered with. This may
be the largest affront to openID's UCI design goal if the user cannot
modify the request, however without some sort of smart client it is
only attackers who might modify it today.
2. Encrypting and audience restricting the returned authenticator
token. NIST is clear that the "Secondary Authenticator" token must
be protected from interception for LoA 2. This is interpreted for
other protocols as encrypting the token at the OP for the RP, or
passing the token directly from the OP to RP.
This could be added to openID if there was a will, however some will
legitimately ask if it is still openID once we start matching features
with SAML?
John B.
On 9-Jun-09, at 12:53 AM, Allen Tom wrote:
John Bradley wrote:
There is also nothing to stop the OP from checking the referrer,
if the referring site is different from the return_to that is
suspicious.
The primary attack vector for phishing tends to be IM, so there
would be no referrer.
If his is used on a web site it seems like a lot of trouble to go
to. They are all ready on a bad site.
Another attack vector could be a message board, which isn't
necessarily a malicious message board controlled by the attacker.
The scenario is that the attacker posts a link on the message board
saying "check out my photos, click here to continue" and the victim
examines the link and trusts the OP's domain. The OP then redirects
to the attacker's site.
As I said earlier, this scenario isnt' really that much different
than TinyURLs.
I will throw in signed requests again because I have been asked why
openID doesn't support that by some large potential RPs.
Requiring the RP to sign the request using a shared secret would be
more consistent with other auth protocols, however it would probably
require the RP to pre-register with each OP. This breaks a lot of
the autoconfiguration/autodiscovery features of OpenID.
Thanks
Allen
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
