Question

I have just debugged a piece of my php code where my login code was not validating the request properly. I had somehow skipped using the ->validate() function and one of my website testers managed to log into an admin account by getting the response from google (below) and changing his email to the admin email.

http://mydomain/login/?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fud&openid.response_nonce=2013-02-15T03%3A56%3A27ZY153c0JFI0G5wA&openid.return_to=http%3A%2F%2Flocalhost%2Flogin%2F&openid.assoc_handle=AMlYA9UI33WW3XfuQGjITXSgB0a0x8nsqD91iuWK9mdvwyBm4EEbk08g&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle%2Cns.ext1%2Cext1.mode%2Cext1.type.namePerson_first%2Cext1.value.namePerson_first%2Cext1.type.namePerson_last%2Cext1.value.namePerson_last%2Cext1.type.contact_email%2Cext1.value.contact_email&openid.sig=laAMatkmFjOPrKPsmaIEg%3D&openid.identity=https3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DAawnUG6Mr7_ynO1mN-fThr9wbOo&openid.claimed_id=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%OawnUG6Mr7_ymuB1mN-fTFhr9wbOo&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ext1.mode=fetch_response&openid.ext1.type.namePerson_first=http%3A%2F%2Faxschema.org%2FnamePerson%2Ffirst&openid.ext1.value.namePerson_first=T&openid.ext1.type.namePerson_last=http%3A%2F%2Faxschema.org%2FnamePerson%2Flast&openid.ext1.value.namePerson_last=M&openid.ext1.type.contact_email=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ext1.value.contact_email=**myemail%email.com**

This got us fairly interested in how open id validates, using the validate() function, where the request came from, and gets sent back to the right source, and catches anything that is not sent back directly from the openid server?
Are the sig or idenitiy variables being used as some sort public/private key system?

If someone could help me understand that would be cool.

Thanks alot

Answer 1

A positive assertion that’s returned from the provider contains a field called openid.signed which is used on the consumer side to verify the signature held in openid.sig. The process of generating / verifying the signature is outlined here.

From the assertion you’ve shown, these are the signed fields:

op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle,ns.ext1,
ext1.mode,ext1.type.namePerson_first,ext1.value.namePerson_first,
ext1.type.namePerson_last,ext1.value.namePerson_last,ext1.type.contact_email,
ext1.value.contact_email

You can see that ext1.value.contact_email is one of the signed fields and is therefore part of the signature, thus if the signature matches you can be sure that the value has not been tampered with.

The assoc_handle refers to the shared secret that’s established between the consumer and provider during the associate method. This shared secret is used to generate a keyed hash of the signed field values, forming the signature to compare against.

If the shared secret cannot be found, the check_authentication method must be used, outlined here and used here.