Hey. I am referring to section 2.3. "Token Credentials" of the IETF draft here.
The example is missing the oauth_token entry. I assume this is just a mistake in the docs, or has other reasons. Is that correct? To quote: >When making the request, the client authenticates using the >client credentials as well as the temporary credentials. The >temporary credentials are used as a substitute for token >credentials in the authenticated request and transmitted >using the oauth_token parameter. Alright, so the 2.3 step needs to have oauth_token set to the temp token obtained as per section 2.1 and has to be signed using the temp token's secret. Now we take a look at twitter's oauth/access_token, which implements this step. You would assume that it is necessary to sign the request using the secret. However, twitter also accepts an empty secret. It accepts "consumersecret&" as key for HMAC-SHA1. That seems wrong to me. Am I missing something here? Without the token secret, if someone sniffed the temp token (from a URL's query string) and the consumer key and secret (not hard to grab those from a desktop application), he would have a small time frame to grab the authenticated token. He would not be able to do that if twitter correctly verified the signature using the temp token's secret. This all assuming that the attacker was able to read GET query parameters, but not HTTP response bodies. Also, the oauth_verifier destroys this scenario, but Twitter doesn't always seem to use that either. To summarize, twitter accepts requests to oauth/access_token both with the temp secret and with an empty temp secret. Which probably means they deliberately choose this to enable web applications to use OAuth without having to store all the temp tokens' secrets. Is that a good idea? So I am not saying there is a security flaw at twitter, I noticed this and wanted to get some opinions from you guys. Thanks! -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
