In the past, several security related issues have been raised against OpenID. This is an attempt to consolidate the list and agree on an approach as we move forward. Note that the issues listed here aren't just protocol related. They are a combination of protocol shortcomings, browser (medium) and deployment practices.

Phishing

There are two common phishing attacks in the OpenID Ecosystem

1. Phished OP Page - A rogue RP can redirect the user to a phished OP page where the user will be tricked into entering their OP credentials.
2. Realm Spoofing - A malicious RP can craft an authentication Request with an openid.realm set to a trusted domain and the return_to pointing back to it's own page. Without the Realm/Return_to validation the user's OP will assert to the user that they're signing into the trusted domain, when in fact, they're being redirected back to the malicious RP.

Both of these issues are explained in more detail here - http://wiki.openid.net/OpenID_Phishing_Brainstorm
More information on phishing can be found here -  http://en.wikipedia.org/wiki/Phishing

Man-in-the-middle Attacks

• In OpenID, the connection is negotiated over DH (Diffie-Hellman) which is subjected to interception attacks.
• In the Diffie-Hellman association session, the user of ephemeral-ephemeral Diffie-Hellman without built-in authentication is non-conformant with the referenced RFC 2631 and introduces a serious risk of IdP Masquerade (TBD: Add reference).

More information on Diffie-Hellman can be found here - http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
More details on Man in the middle attacks can be found here - http://en.wikipedia.org/wiki/Man-in-the-middle_attack

Session Related Attacks

OpenID (or any Web SSO protocol for that matter) facilitates user having several active authenticated sessions. It provides more opportunities for a malicious site to exploit the vulnerabilities of OP and other RPs since the user already has an authenticated session. Some of the specific issues are listed below:

Session Swapping

This issue has been mentioned in the Robust Defenses for Cross-Site Request Forgery (Barth, Jackson, Mitchell) as well as Project OpenID:Security Model Analysis (Newman, Lingamneni). Both papers are attached in the resources section.

The protocol doesn't suggest a mechanism to bind the OpenID session to the user’s browser, letting a web attacker force the user’s browser to initialize a session authenticated as the attacker. And thus a attacker can initiate the session at the RP, authenticate at the OP and fool the victim to have access at the RP (even though the user is logged in as the attacker). User will not realize that he is logged in as the attacker and may reveal sensitive information at the RP. 

CSRF (TBD)
once the user is logged in attackers might be able to execute a series of CSRF (Cross-site request forgery) attacks against the OP  or other RP sites where the user is logged in.

XSS(TBD)
once the user is logged in attackers might be able to execute a series of XSS (Cross-site Scripting) attacks against the OP  or other RP sites where the user is logged in.

Privacy

Your OpenID provider will know every site you log into using its credentials. There isn’t any way in the protocol (unlike Information Cards) to hide this information from the IdP. Since the OP becomes a central place for all login activity across all sites, a malicious OP can easily track user's activity on the internet.

Centralized Risk

Your IdP account is much more valuable to the hackers. They hack once and have access to multiple sites. The more successful an IdP gets, the more lucrative it becomes for hackers.Not many IdPs today offer step-up authentication and/or authentication levels(which can vary as per the context of the transaction). And hence either the experience is overkill for no value transactions or less secure for value transactions.

Weak backend Security

 Many sites provide strong authentication methods for users to log in; but allow email based account recovery. Account recovery that's merely dependent on email access should be unacceptable for any OP.

Co-relation

If the users uses the same OpenID identifier at various RP sites, the RP sites can get together and co-relate user's information / activity. If the user has independent logins at various RP sites, this is not possible or at least harder to achieve.

Identifier Strings

There are several issues with having a user enter his OpenID identifier

Usability - Remembering / entering an identifier string is a usability challenge for the users. It's get even more difficult since not all OPs uses the same style (e.g. user.op.com or op.com/user or whatever.com/openid/user)

Privacy - User entering the same identifier at multiple places allow for co-relation by RPs as mentioned earlier.

Security - Attacker can enter identifiers that can result in buffer overflow, injection, directory traversal attacks at RP sites.OpenID identifier is simply a URL. When a user enters the identifier at a site, the site has to  download the URL and data from an arbitrary hosts which is extremely risky. As an example, an attacker entering the identifier as www.youtube.com/largemovie.flv can potentially result in DoS attacks against the RP. For more details on the issue, see the paper by Eugene and Vlad Tsyrklevich (attached in the Resources section).

Replay attacks (TBD)

Many RPs don’t check for nonces and aren’t protected against replay attacks.

Recycling (TBD)

OP policy of recycling identifiers isn’t the same as RP’s policy. OP’s don’t communicate to RPs while recycling an identifier.

Silent Authentication (TBD)