[security] Tailoring headers to Consumers

[SitG Admin]

(Slightly modified from the version posted to general@; SSH isn't 
necessary, introducing a web-based interface may expose the site to 
that attack avenue, but if the interface is tightly restricted to 
this purpose an attacker will find that it is useless unless they 
*also* compromise the Provider.)

Something that I've been contemplating for a bit, and generally 
having a disturbing lack of success finding problems with, is the 
idea of having my server only include some OpenID headers when myself 
or a pre-identified Relying Party (by IP and/or UserAgent) requests 
the page. Visitors could of course adjust their own UserAgent (to see 
my OpenID) with ease; that's not what I'm trying to affect, though. 
The *point* would be to control whether a non-hostile Consumer sees 
*any* OpenID headers at my site; if not, fraudulently representing 
themselves as me would be difficult, even if they *could* spoof my 
credentials. This could provide a layer of protection against 
Providers that turn out to be hostile or vulnerable to a hostile 
party's theft of their authentication records. There are also some 
possible benefits in being able to effectively use *multiple* 
Providers, simultaneously; for unimportant sites or leaving comments, 
a Provider with weak authentication, while for important sites, a 
Provider with biometrics and smart cards and fractally changing 
passwords.

Since I'm unlikely to know the library (this affects UserAgent) a 
Consumer is using when I first try to sign in there, I might have to 
try once while looking at my access logs to figure it out. This is an 
inconvenience, but one I'm okay with; I can probably figure out the 
IP a Consumer is coming from by looking at the address of the server 
that the site I'm trying to log in to is hosted on. It's the Virtual 
Hosts that give me pause, though in *theory* any site that's 
large/important enough for me to worry about it being unintentionally 
"whitelisted" as a Consumer, will have its own dedicated IP address 
anyway.

Even if there aren't any *problems*, the practical difficulty in 
implementing this will probably ensure that most people don't use it. 
I think it looks good as a user-side security measure, but for users 
whose webhosts include static content and don't allow server-side 
scripting, it won't be possible. Even if every Relying Party were to 
identify itself in the UserAgent string by the website it was 
originating from (and that information was available on the site 
during login), many users might simply not be *able* to do anything 
with that information.

-Shade