4 ms·

It would be possible to obfuscate a secret by storing it in several parts and combining them at run time. Still very far from secure, but this would require muc

It would be possible to obfuscate a secret by storing it in several parts and combining them at run time. Still very far from secure, but this would require much more effort to extract the secret from the app. Anyone: what is best practice here (Android and/or iOS)? Edit: Storing application secrets in Android's credential storage [1]. I have no idea how secure this actually is. Should I obfuscate OAuth consumer secret stored by Android app? [2] [1] http://nelenkov.blogspot.co.uk/2012/05/storing-application-secrets-in-androids.html http://nelenkov.blogspot.co.uk/2012/05/storing-application-s... [2] http://stackoverflow.com/questions/7121966/should-i-obfuscate-oauth-consumer-secret-stored-by-android-app http://stackoverflow.com/questions/7121966/should-i-obfuscat...

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.
JoachimSchipper 14y ago
For Android, I suppose you could just run a Java bytecode obfuscator before converting the bytecode to Dalvik. There doesn't seem to be something comparable for iOS. One simple solution is to set N-1 arrays to random data (hardcoded or generated at compile time) and set the last array to the real secret XOR random array #1 XOR random array #2 XOR ... XOR random array #N-1; this doesn't exactly stop a determined attacker, but it does stop "strings".
- objclxt 14y ago
  There's very little point obfuscating strings in iOS - since you can attach a debugger to the binary itself on jailbroken handsets (or using cycript) you can step through to the method(s) that use the secret keys and pull them out from there.
vidarh 14y ago
Unless you know the device isn't rooted this doesn't really achieve very much. On a rooted device an "attacker" could have replaced the crede tial storage with something that will conveniently store the data unprotected. It is helpful as a way of ensuring random applications don't get hold of the data, but not for keeping the data from a determined user.
dexen 14y ago
> It would be possible to obfuscate a secret by storing it in several parts and combining them at run time. Then run `strings' on virtual memory image of the offending process. Same difference.

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.

JoachimSchipper 14y ago

For Android, I suppose you could just run a Java bytecode obfuscator before converting the bytecode to Dalvik. There doesn't seem to be something comparable for iOS. One simple solution is to set N-1 arrays to random data (hardcoded or generated at compile time) and set the last array to the real secret XOR random array #1 XOR random array #2 XOR ... XOR random array #N-1; this doesn't exactly stop a determined attacker, but it does stop "strings".

objclxt 14y ago
There's very little point obfuscating strings in iOS - since you can attach a debugger to the binary itself on jailbroken handsets (or using cycript) you can step through to the method(s) that use the secret keys and pull them out from there.

vidarh 14y ago

Unless you know the device isn't rooted this doesn't really achieve very much. On a rooted device an "attacker" could have replaced the crede tial storage with something that will conveniently store the data unprotected. It is helpful as a way of ensuring random applications don't get hold of the data, but not for keeping the data from a determined user.

dexen 14y ago

> It would be possible to obfuscate a secret by storing it in several parts and combining them at run time. Then run `strings' on virtual memory image of the offending process. Same difference.