At 5:10 PM +0200 7/19/13, Torsten Lodderstedt wrote:
How does the server ensure the caller is the user represented by this URL?
OpenID, presumably.
So for example, how would you prevent an attacker from sending your user id URL to the server (and in turn impersonating you on this server)?
We wouldn't. Attackers can't be controlled. This is where "It SHOULD NOT be used as an insecure form of access protection." may require stronger wording; "insecure" implies that the problem is only one of HTTP vs HTTPS, and simple sites can rely on the presented URL if they use SSL to protect the connection. The user does have to be authorized previously (though the presented URL may initiate an OpenID process), and *I think* there should be at least one means of maintaining statefulness on that session *other than* the User field (even if it's just a cookie) unless the User field will be modified on the spot to include server-provided identifying information (in which case it would just be replicating cookie functionality) and then the "insecure" recommendation is sufficient because it prevents eavesdroppers on the network from stealing that token.
From reading the cross-posted proposal, I gather that they're intending this to be used for auxiliary metadata, which implies discrepancy checks for suddenly vanishing/switching authorization or User fields. I believe, then, that a User field should *not* act like a cookie, since combining these just simplifies matters for an attacker (who only needs to steal one of them).
I'm unclear, however, how useful this metadata *would* be for invalid requests; sure, if the user goes away entirely, you can block based on User, but if they have over-active spiders running about "in the wild" with their User URI and their login credentials (it *sounds* unlikely, but their IDP could potentially circumvent even password-changes, for the sake of monetizing its userbase, and the user might be forced by circumstance into staying with that IDP to retain their social identity/reputation), how would the server block these (or feed them less information) while letting the *user* through? If the server supported minor changes to the URI (which would not affect resolution to its intended resource), and provided access to a user-configurable whitelist, then the user would have to keep track of non-memorable distinctions or lose access to the site, and any access-reset mechanism would be exploitable by the IDP to restore *its* spying. Simple servers wouldn't implement such complex controls anyway, and the feature seems out-of-scope for the proposed User field, so I'm curious about the exact use-cases they have in mind.
-Shade _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
