[OpenID] Abusing Authentication Failure messages

[John Bradley]

Agreed,

It is up to the RP to use return to pass additional information, though the RP needs to sign anything that is passed that way.

OpenID is by design a RESTful protocol.   Preserving state on the RP is not a requirement.

You can optimize the flow by caching the results of discovery.   However I the RP must always fully validate the assertion.

OpenID supports unsolicited assertions as well, where there is no request.

It is up to the RP to preform session management, as Andrew points out you can pass things threw the return_to, though unless they are specifically required for the authentication flow(replay detection for openid 1.0 etc)  that is probably a bad design.

John B.
On 2010-08-20, at 10:17 AM, 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.
> 
> 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
> 
> _______________________________________________
> 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/20100821/9d9df9d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100821/9d9df9d6/attachment.bin>