Concerning oauth spec, there are 2 version v1.0, v1.0a except for IETF draft. Because v1.0 has a security weakness related to 'oauth_callback', v1.0a was published. Though current Twitter OAuth is based on v1.0, Google OAuth is based on v1.0a and specific parameters are also available. So those 2 version specs make you confused.
On 12月8日, 午前1:35, KiNgMaR <[email protected]> wrote: > 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.
