providers and trust (was: LJ munging...)

[Mark Rafn]

I thought I once saw a security analysis of OpenID, but couldn't find it 
on the wiki.  Has anyone put together a list of things that a consumer is 
implicitly trusting when it decides that an OpenID user is the same person 
as last time it saw that claimed identity?

Obvious points of failure resulting in false authentication:
   The user can be sharing identity info or just be bad with security
   For every URL retrieved (normalized claimed identity and all redirects):
      DNS must be trusted.
      HTTP server must be trusted not to redirect incorrectly.
      HTTP content must be trusted (final resolved URL only).
      Any host on the route must be trusted unless SSL is used and the 
cert is required to be signed and valid.
   Identity server must be trusted.
   Identity server's authentication method (password, cert, cookie, 
whatever) must be trusted.

There may be others.  Interestingly, I don't think the delegate identity 
URL needs to be trusted.  Compromise of that URL may lead to failure to 
authenticate, but not false positive authentication.

> Doug Bell wrote:
>>  Developers: As a consumer, could you trust certain providers more than
>>  other providers?

My gut says I should trust certain providers (based on server and/or 
delegated URL) differently than others.  And maybe I trust top-level 
claimed identies more than those that contain slashes.  But on second 
thought, this may be wrong.  I'd love to hear more opinions on what 
attacks are mitigated by this type of filtering.

>>  In other words, could you take the last delegate and keep
>>  a record of whether or not to trust OpenIDs from that delegate?

I'd recommend to rate servers on trust, not delegate identities.  Though 
maybe you want both, and claimed identity while you're at it.

>> Perhaps include a special record for those who seem to manage only 
>> their own OpenID from their own server ( if ($provider_url =~ 
>> /$openID/) { return lookup_trust("private_id"); } else { return 
>> lookup_trust($provider_url) }
>> ).

I think that's the wrong axis of checking.  I don't really care that they 
have the same identity and server, I care that the server they use does 
some actual authentication rather than just saying "yeah, it's him" to 
every request.

I'm not sure this is needed, though, as it's really no different from 
non-OpenID auth.  If a server is promiscuous or buggily insecure, 
users who use that service can have their identity spoofed.  Users who 
pick bad passwords (or post them on bugmenot.com) can likewise be spoofed.

Note that spoofing is equally possible due to bad security at the 
normalized URL, any URL in the redirect chain to the canonical URL, the 
delegate URL, _OR_ the OpenID server.  Keeping users from picking faulty 
OpenID hosts seems mildly easier than keeping them from picking bad 
passwords.  Which is to say "impossible."

On Wed, 21 Sep 2005, Lukas Leander Rosenstock wrote:
> I'm nearly sure this will happen. When OpenID has become more popular and is 
> therefore also used by spammers some sites might, for example, trust a 
> *.livejournal.com-user more than a *.service-i-have-never-heard-of-before.com 
> user. But we have to be careful to not lock the latter out completely, 
> otherwise OpenIDs from an unknown server will become practically useless.

Consumers get to choose.  It's perfectly valid to only accept OpenID 
logins from a known list of servers and disallow delegation entirely. 
It's a tradeoff that ID consumers must make between being compatible with 
more users and accepting that users might make risky choices in security 
matters.

> However, if an OpenID is a top-level-domain, e.g. myname.com, consumers can 
> usually trust them because it is not possibly to register a domain 
> anonymously (as far as I know).

It's trivial to register under a fake name.  It's possible to compromise a 
whole lot of second- and third-level domains, giving you anonymous access 
unless you get caught.

I can't think of any rational reason to trust the contents of
http://somerandomname.org any more than you'd trust 
http://www.bigcompany.com/foo/bar/baz.
--
Mark Rafn    dagon at dagon.net    <http://www.dagon.net/>