3 ms·

Correct me if I'm wrong here but I believe that then all one would need to do is stick an SSL intercepting proxy (such as http://mitmproxy.org/doc/ssl.html http

by pandog 14y ago

Correct me if I'm wrong here but I believe that then all one would need to do is stick an SSL intercepting proxy (such as http://mitmproxy.org/doc/ssl.html http://mitmproxy.org/doc/ssl.html) in the middle and get the keys from there.

JoachimSchipper 14y ago
It's at least possible to accept only the keys from your real servers, which would stop this attack. For what happens in the real world, see Georgiev et al.'s "The most dangerous code in the world" at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-... (spoiler: I described this paper in our internal knowledgebase as "very readable. Promises lots of facepalming and delivers in spades.")
andyjohnson0 14y ago
That depends on how the secret is used by the client to authenticate with the remote service. If the client just sends the secret as part of an authentication request, then a proxy would reveal it. But if some form of challenge/response [1] process is used, where the value sent is derived from the secret and an unpredictable challenge sent by the remote service, then as far as I know a proxy wouldn't help. I don't know enough about the details of the Twitter/DropBox/etc APIs work to know if they use challenge-response. [1] http://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...
deleted 14y ago
[deleted]
lucian1900 14y ago
Only if the app uses the phone's certificate store, as opposed to a hard-coded one.
talaketu 14y ago
Incorrect. The consumer-secret and access-token-secret are not transmitted from client to the server during oauth. They are only used to sign requests.
- xyzzy123 14y ago
  Clarification: For v1. In v2 the secrets just go over SSL.

3 ms·

Correct me if I'm wrong here but I believe that then all one would need to do is stick an SSL intercepting proxy (such as http://mitmproxy.org/doc/ssl.html http

by pandog 14y ago

JoachimSchipper 14y ago
It's at least possible to accept only the keys from your real servers, which would stop this attack. For what happens in the real world, see Georgiev et al.'s "The most dangerous code in the world" at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-... (spoiler: I described this paper in our internal knowledgebase as "very readable. Promises lots of facepalming and delivers in spades.")
andyjohnson0 14y ago
That depends on how the secret is used by the client to authenticate with the remote service. If the client just sends the secret as part of an authentication request, then a proxy would reveal it. But if some form of challenge/response [1] process is used, where the value sent is derived from the secret and an unpredictable challenge sent by the remote service, then as far as I know a proxy wouldn't help. I don't know enough about the details of the Twitter/DropBox/etc APIs work to know if they use challenge-response. [1] http://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...
deleted 14y ago
[deleted]
lucian1900 14y ago
Only if the app uses the phone's certificate store, as opposed to a hard-coded one.
talaketu 14y ago
Incorrect. The consumer-secret and access-token-secret are not transmitted from client to the server during oauth. They are only used to sign requests.
- xyzzy123 14y ago
  Clarification: For v1. In v2 the secrets just go over SSL.