OpenID account security

Many developers often design their system security based on what the software does; this is a mistake you should always design a security system based on what your software might do. I'm quite surprised when people don't understand this, I often think of potential scenarios and discuss flaws in a current implementation based on those scenarios. Just because something doesn't work now, doesn't mean it won't in future. Here I shall discuss three scenarios based on OpenID account security.

Scenario 1 - Automated account compromise

Attack: The attacker constructs a Google query to gather a list of valid OpenID indentity pages, they then use a regular expression to gain the username (OpenID Identifier). The attacker then tries either a dictionary attack or simply uses the username as the password.

Defense:

1. The provider should not allow the same username and password combination. (Every provider I checked allowed this).
2. CAPTCHAS should be used along with brute force defenses. (* Note MyOpenID 3 character CAPTCHAS are useless).
3. By default a identity page shouldn't be public or at least not indexable by search engines.

Scenario 2 - Internal phishing

Attack: A buddy system is launched to enable OpenID users to communicate with each other, the problem is not many providers protect against registration of official looking account names. For example webmaster, root, admin and administrator.

Defense:

1. Obviously prevent users from registering accounts such as admin.

Scenario 3 - A browser zero day

Attack: The bad guys find a cross domain exploit in a major browser, because the passwords on OpenID providers are often saved, the attacker can gather the HTML source and form tokens. Users and web sites are now under full control of the bad guy.

Defense: It's pretty much game over when a cross domain exploit is found but a provider can have systems in place to help minimise damage.

1. Always ask for a password on a site request.
2. If 1 is not practical at least disable any vulnerable browsers from using your site or require a password confirmation for that particular browser.
3. Sensitive information or account actions should always require a password confirmation.