The problem(s) with OpenID
Posted May 28, 2008 7:22 UTC (Wed) by
jamesh (subscriber, #1159)
Parent article:
The problem(s) with OpenID
A lot of the criticism in that article seems to be along the lines that "if implemented badly, OpenID is insecure", rather than "OpenID is inherently insecure".
While DNS poisoning is a problem for an OpenID provider running over HTTP, the same is not true for https identities/providers. There is a caveat here though: you need to make sure you enter the "https://" bit in the OpenID field or you will still be open to poisoning attacks (identity URLs without a scheme default to HTTP, which I guess is a concession to people running their own identity provider).
Similarly, the phishing potential for a provider is highly dependent on the authentication method they employ. While a plain username/password might be susceptible to provider proxying attacks, it isn't the only option. Some options include:
- One time password schemes, or some two factor authentication systems.
- SSL client certificates (an option on myopenid.com).
- Using a system like InfoCard to authenticate the user to the provider.
- Use an out of band authentication mechanism. Jabber was mentioned as an example in another comment. Telephone call based auth is also an option.
The trust vs. identity issue seems a bit out of place. OpenID tells the RP that a user controls a particular URL (to the extent they trust DNS, SSL, etc) nothing more. But once you have that assertion, you can start applying trusted assertions against the URL to the user. So in this sense you can build trust on top of identity. The identity assertion doesn't come out of thin air though.
(
Log in to post comments)