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.
There are two common phishing attacks in the OpenID Ecosystem
More information on phishing can be found here - http://en.wikipedia.org/wiki/Phishing
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 SwappingThis 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.
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.
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.
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.
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
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.
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.
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.
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)