[OpenID] Abusing Authentication Failure messages

Sun Aug 22 11:58:25 UTC 2010

On 21 Aug 2010, at 23:33, Andrew Arnott wrote:

> I don't know why you see this as a security flaw in the protocol.  Your email started out as "hey, I wish a request and associated response could be tied together in my log files" so it seemed like just an inconvenience to you, and now you're talking about a security flaw.  It sounds like you have multiple topics in your email now.

I was clearly introducing the issue.  If request and response were tied by a unique ID, it would be clear for the RP to identify false failure responses and ignore them; since no request was made with a matching ID.  This has nothing to do with logging; though session management at the RP's side would definitely be helped by this as well; being able to cache request discovery information for matching against a response in a set hashed by ID.

> Maarten said:
> In the case of a failure response, however, there is a significant lack of useful information passed from the OP to the RP.  This lack of useful information makes it impossible for the RP to verify that the response did originate from the OP. 
> 
> If it's a failure response, you're absolutely right.  Anyone can forge a failure response.  What would the RP do differently if it knew for sure whether the failure came from the OP or not?  If it makes any difference to your RP, I'm sure we'd be interested to know what that difference would be.  

I would think the RP would clean up the discovery information from the request when it receives either a successful or failure response.  In doing so, making a successful authentication response that comes in later unverifiable.

>  
> Unfortunately for the RP, (and conveniently for an attacker), the response is sent via indirect communication (via the User Agent); so the RP has no clue whatsoever where the response came from or who crafted it.  There is no association handle, no signature, no nonce, no nothing.
> 
> Again, for a failure response, that's true -- unless you utilize the return_to parameter as we've described in prior emails.  But what's the problem with this?  Unless you have very stringent security requirements that I can't think of at the moment, since a failure response gets the user no security elevation from the RP, why would an attack do this?  He would gain anything, or cause the site itself to suffer and failure responses are very cheap to process.

Did I perhaps misunderstand how authentication responses are to be handled?  I was under the assumption that it was necessary for the RP to retain discovery information it obtained when creating the request (such as its association with the OP).  If this is the case, then, as I said above, a failure response, legit or not, would be a sign that the RP can clean up its request discovery information; effectively making any legit response that comes in later unverifiable.

If no information need be retained from the request then I expect the OpenID spec requires the RP to just blindly accept any authentication response and apply it to the user's session (after first verifying its signature - if it's a successful response). If this is the case, then IDs to tie a response to a request are perhaps not necessary for the purpose of validating a successful response; but that also means that the entire authentication operation is stateless:  If Alice comes back with a successful authentication response to her RP, the RP will log Alice in on her session.  If later, Alice's user agent sends an authentication failed response to the RP, the RP, having no context to verify this response in, SHOULD log Alice back out of her session.  Correct?  If so, any site open in a separate tab in Alice's browser can still keep Alice from staying logged in on any targetted RP by simply automating authentication failed responses to the RP.

If, however, the RP only accepted responses that had an ID matching one of its requests, then it would only accept ONE authentication response, clean up its request data, and stop accepting anything else unless it first makes a new authentication request.  That still means the authentication failed response would need to be signed to avoid tampering.

> OpenID advocates and authors take security seriously, and they mean to improve it in future versions.  To say all security features are optional is a very poor statement to make, as an authentication protocol with no required security features is ludicrous.

Clearly I was exaggerating since I didn't feel like copying each instance of optional security feature from the spec for you.  However, consider the fact that association is optional, signing (even without association) is optional, realm validation is optional, responses are allowed to be sent over clear-text transports (revealing identity information to intermediate parties), etc.

As an end-user, I would trust a site that claimed OpenID support to guard my safety and privacy more if I knew the specification required it to be stringent in the above matters.

> But perhaps you can ask additional questions (if you have any that this email doesn't answer) in a more "help me understand" attitude?  

I'm really mostly just concerned.  If you interpreted that as a bad attitude, I'm sure you can look past it and discuss the issues raised.  This thread isn't so much about "help me understand how to implement OpenID", but rather, "does the OpenID protocol really have these shortcomings or are there provisions in place that I must have missed to ameliorate or even close these holes?"

> 
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
> 
> 
> On Sat, Aug 21, 2010 at 2:05 PM, Maarten Billemont <lhunath at gmail.com> wrote:
> 
> On 20 Aug 2010, at 16:17, Andrew Arnott wrote:
> 
>> I don't consider this a flaw at all.  In fact you can solve it yourself today, in total compliance with the OpenID spec.  
>> 
>> Use the return_to parameter to add whatever unique ID you wish was there.  Then in your logs, you'll see the ID on the outgoing request (if you log it) and on the response (via the incoming HTTP indirect message).  
>> 
>> Problem solved, right?  It's totally up to the RP (you) to leverage this hidden "feature" of ways to use return_to.
> 
> Might I ask what the wisdom behind this is?
> 
> I have the feeling OpenID is all about a way of authenticating users and exchanging identity information but utter minimal requirements to do that in a secure fashion.  All features that are there to protect against known and proven attack vectors are optional.  And as indicated by this thread, some attack vectors aren't even dealt with by the protocol: one would need to do silly undocumented stuff to existing parameters or add extensions to the protocol.  You could say, the OpenID protocol is the exact opposite of "Secure By Default".  And designing a protocol that way only encourages lazy implementations that have no regard for user privacy concerns.
> 
> Do the OpenID designers hold security in a low regard or does security come second to "ease of implementation" (frankly, a secure protocol is just as easily adopted given good reference implementations).  Perhaps I'm not seeing all the reasons why OpenID was designed the way it was - can anyone shed some light?
> 
>> 
>> In particular, DotNetOpenAuth utilizes return_to when its optional feature is activated that disables "unsolicited assertions", which guarantees that each authentication response starts with an authentication request that originated at the RP.  We had a signed nonce from the RP to the return_to, and verify it when it comes back.  Again, this is only if you wanted to disable unsolicited assertions deliberately for some reason.
>> 
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
>> 
>> 
>> On Fri, Aug 20, 2010 at 2:12 AM, Maarten Billemont <lhunath at gmail.com> wrote:
>> It has always bothered me that the OpenID protocol does not assign a unique ID to requests that is required to be repeated in the request's response.  This makes it annoying to cleanly identify whether a response matches a particular request; instead relying on chronology (response Y comes after request X?  It must be a response to X!).
>> 
>> This is an annoyance, yet, in the case of successful authentication responses, not a disaster: The response can be signed and verified.
>> 
>> In the case of a failure response, however, there is a significant lack of useful information passed from the OP to the RP.  This lack of useful information makes it impossible for the RP to verify that the response did originate from the OP.  Unfortunately for the RP, (and conveniently for an attacker), the response is sent via indirect communication (via the User Agent); so the RP has no clue whatsoever where the response came from or who crafted it.  There is no association handle, no signature, no nonce, no nothing.
>> 
>> Does that mean that to sabotage an OpenID site's authentication process, all I have to do is craft a website which, when opened by the user in a separate tab, continuously makes requests to the RP providing authentication failure responses?
>> 
>> Am I missing something here, or is the OpenID protocol really so flawed?  And if it is, can I expect anyone to fix the protocol any time soon?
>> 
>> _______________________________________________
>> general mailing list
>> general at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-general
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100822/c6f8b461/attachment.html>