security

[Dan Lyke]

On Tue, 24 Oct 2006 18:54:06 -0700, Eddy Nigg (StartCom Ltd.) wrote:
> - If an IDP (perhaps you) is not required to run in secured mode,  
> than the user specific data might get compromised and the chances
> are too high...I can't allow access to critical area, where a
> user/password pair might have been transfered in plain...

I've already laid out my reasons why I believe that authentication of  
the user to the Identity Provider is between the user and the Identity  
Provider. I think it's a good idea, but I use an SSH tunnel between me  
and a proxy server running on my colo server, so if I want to use HTTP  
(albeit over an SSH channel) between me and my colo server (which will  
be my identity provider), that's my own business.

> - If a RP isn't required to run in secured mode, than chances are,  
> that half of the secret of the user might get compromised (i.e.
> the user URI is half of the secret).

No, it's not. In fact the user URI is published widely and isn't a  
secret at all. I use http://danlyke.livejournal.com/ and  
http://danlyke.pip.verisignlabs.com/ right now, and I'll be handing  
one of those (or something similar) over to anyone *on the net* who  
wants an identifier for me. It's no more secret than my name.

> - If a RP might transfer or receive data unsecured (and even
> unencrypted) between the IDP and itself, than again part of the data  
> can get compromised.

So to be *very* specific:

Your fear is that a compromise in the DNS services of the Relying  
Party could allow an attacker to insert a proxy between the Identity  
Provider and the Relying Party which could cause an intervening party  
to authenticate a user who shouldn't be authenticated.

That leads to two questions:

1. What exploits do you think this enables? (I can think of a couple)
2. What's the relative difficulty of setting up an exploit like this  
versus other exploits, how likely is it for communications between the  
Relying Party and the Identity Provider to actually be compromised,  
and what other exploits are enabled by such a compromise.

Throwing encryption at a problem *can* be the right solution, but  
often, as in the "we'll just encrypt it twice!" fallacy, using  
encryption without understanding the basic issues (ie: the user  
identifier URI isn't secret) usually just gives a false sense of  
security without addressing the underlying insecurities.

#1 means that all communication between the Relying Party and the IdP  
Endpoint URL and the Claimed Identifier would need to be HTTPS.

Are any of the LJ or Verisign guys here want to give us a probability  
of LiveJournal making Claimed Identifiers (ie: all LiveJournal user  
URLs and all VerisignLabs URLs) HTTPS?

My guess is somewhere between "snowball's chance in hell" and "zero",  
because that would mean allocating a separate IP address to all  
LiveJournal users (http://username.livejournal.com/) or PIP users  
(http://username.pip.verisignlabs.com/), not to mention the additional  
server and compute costs of making everything HTTPS, a rough guess is  
that it'd be substantial.

So I suggest that we find another solution.

Dan