Hacker News Reader

Comment by andyjohnson0 | Hacker News Reader

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-s...

[2] http://stackoverflow.com/questions/7121966/should-i-obfuscat...

View on HN

> 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.

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) in the middle and get the keys from there.

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-... (spoiler: I described this paper in our internal knowledgebase as "very readable. Promises lots of facepalming and delivers in spades.")

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_auth...

Only if the app uses the phone's certificate store, as opposed to a hard-coded one.

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.

Clarification: For v1. In v2 the secrets just go over SSL.

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".

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.

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.

Reply on news.ycombinator.com