Download & Extend
OpenID Provider » Issues

can't login to ikiwiki.info (perl's Net-OpenID-Consumer?)

Posted by anarcat on May 15, 2011 at 7:00pm
Project:OpenID Provider
Version:6.x-1.0-beta6
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (fixed)
Issue tags:interoperability

Issue Summary

I cannot login to ikiwiki.info (and probably no other Perl-backed website) with the latest OpenID Provider. The error is:

Error: OpenID failure: naive_verify_failed_return: Provider says signature is invalid
Login or register to post comments

Comments

#1

Posted by anarcat on May 15, 2011 at 7:53pm

The perl code debugging tells me there is something missing from the association:

[Sun May 15 15:32:11 2011] [error] [client 192.168.0.3] [DEBUG Net::OpenID::Consumer] handle_assoc: dumb mode: no_handle, referer: http://anarcat.ath.cx/hamwiki/ikiwiki.cgi?page=Main_Page&do=edit

thanks for that... unfortunately, the openid_provider.module doesn't have such debugging, which makes things quite hard to figure out...

The issue here is the Relying Party (RP) isn't able to store the association key for some reason (seems to be a limitation in Ikiwiki), so it falls back to some dumber mode:

# return a handle for an identity server, or undef if
# no local storage/cache is available, in which case the caller
# goes into dumb consumer mode.  will do a POST and allocate
# a new assoc_handle if none is found, or has expired

The OpenID 2.0 standard states that:

openid.assoc_handle
  Value: (optional) A handle for an association between the Relying Party and the OP that SHOULD be used to sign the response.

  Note: If no association handle is sent, the transaction will take place in Stateless Mode.

Stateless mode is:

11.4.2.  Verifying Directly with the OpenID Provider

To have the signature verification performed by the OP, the Relying Party sends a direct request to the OP. To verify the signature, the OP uses a private association that was generated when it issued the positive assertion.

https://openid.net/specs/openid-authentication-2_0.html#check_auth

So it seems like this is part of the standard that isn't supported... ?

#2

Posted by anarcat on May 15, 2011 at 9:01pm

Indeed, openid_provider_verification_response() mentions it supports

// 9.2.2.2. Verifying Directly with the Identity Provider
, but then goes around checking in its tables to see if the association handle is present, which seems to be a mistake - it should just validate the signature it received.

This could be related to that long-lasting feature request: #506530: Private association support. Or it's just a problem with client malformed data (e.g. #831162: cannot login on stackoverflow or dotnetopenid sites).

I do not have duplicate query string elements as in #831162: cannot login on stackoverflow or dotnetopenid sites though, so my problem is elsewhere (most notably: no assoc_handle is sent from the RP). According to the spec the transaction is supposed to take place in stateless mode, but doesn't explain clearly how this is supposed to happen.

#3

Posted by anarcat on May 15, 2011 at 9:32pm
Status:active» needs review

I am running with this patch in production, but I am worried it is incorrect, especially due to this part of the spec:

For verifying signatures an OP MUST only use private associations and MUST NOT use associations that have shared keys. If the verification request contains a handle for a shared association, it means the Relying Party no longer knows the shared secret, or an entity other than the RP (e.g. an attacker) has established this association with the OP.

However, maybe a private association is exactly what we're doing here... we're creating a new 'nonce' that is known to the OP and delievered to the RP.

The problem is that it seems that generating nonces like this all the time is not necessarily a good idea:

http://lists.openid.net/pipermail/openid-general/2009-April/017584.html

... as it can lead to a DOS attack on the provider.

I have nevertheless produced a patch that fix authentication on ikiwiki sites, and probably others that do not have their own storage of openid data. I would appreciate feedback regarding the above issues.

AttachmentSize
1158356_ikiwiki.patch 1.57 KB

#4

Posted by anarcat on June 23, 2011 at 1:45pm
Status:needs review» fixed

This has been working fine in production for a while, committed.

#5

Posted by System Message on July 7, 2011 at 1:52pm
Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#6

Posted by anarcat on January 29, 2012 at 8:00pm
Version:6.x-1.x-dev» 6.x-1.0-beta6
Status:closed (fixed)» needs work

So it seems I broke this recently. Now I can't login to ikiwiki.info anymore.

#7

Posted by anarcat on January 30, 2012 at 4:41am
Status:needs work» fixed

phew! fixed this again, now for good i think. this one was really hairy. see commits b7a1c8a68711674748de422d2a7a58cba42e5673 and 3aa74dda367d7e15e0379f13db2cf74f001b1d35 for more information.

#8

Posted by anarcat on January 30, 2012 at 4:47am

For the record, this is how to enable openid debugging in ikiwiki:

--- /usr/share/perl5/IkiWiki/Plugin/openid.pm.orig      2012-01-29 23:45:45.707281457 -0500
+++ /usr/share/perl5/IkiWiki/Plugin/openid.pm   2012-01-29 19:00:07.883446184 -0500
@@ -258,6 +258,7 @@
                args => $q,
                consumer_secret => sub { return shift()+$secret },
                required_root => $cgiurl,
+               debug => 1,
        );
}

#9

Posted by System Message on February 13, 2012 at 4:50am
Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.