4 ms·

This is a problem I've regularly faced with it android apps . Possible solutions since many people seem to be asking that. - Fetch credentials and keys on logi

by shade23 10y ago

This is a problem I've regularly faced with it android apps . Possible solutions since many people seem to be asking that. - Fetch credentials and keys on login and then save them in an encrypted manner in - SQLite Encrypted DB - Android Services like KeyStore[1] - AccountManager lets you save metadata[2] But the way I mostly end up using which provides protection from a lot of Reverse Engineering Tools(JADX,dex2jar,smali) is: Use Enums instead of String constants. Using ``` public enum Key { Key1("keyValue"); String keyVal; private Key(String keyVal) { this.keyVal = keyVal; } } ``` obfuscates the `keyVal` from many class decompilers. I'd love better ways to do this. But when you do Android development (like when you do Front End web dev), its easier to just assume that everything you wish to keep private will be visible and avoid keeping/saving critical information on the client app. [1]:https://developer.android.com/training/articles/keystore.html https://developer.android.com/training/articles/keystore.htm... [2]:https://developer.android.com/reference/android/accounts/AccountManager.html#getUserData(android.accounts.Account https://developer.android.com/reference/android/accounts/Acc..., java.lang.String)

BoorishBears 10y ago
Stuff in native code (for example, XOR'd keys) is also marginally more difficult to access. It won't protect you from someone actively attacking your app, but it makes you less likely to get hit by people running automated scraping on apps for keys. At the end of the day it's all security by obscurity and the real answer is proxying calls or TVMs to limit what individual keys can do, but it doesn't hurt not to be the lowest hanging fruit either.
skybrian 10y ago
How does using an enum help? You still have a string literal in your code. Shouldn't that be easy to find?
saurik 10y ago
All of your "solutions" still involve having the keys on an untrusted computer: the one in my hand; it isn't correct enough to say it is "easier to just assume that everything you wish to keep private will be visible"... it absolutely fundamentally doesn't work to put something sensitive in the hands of the attacker, even momentarily. For people who just can't grok this, imagine some incredibly trivial to pull off scenarios: your app is modified, the Java virtual machine is modified, the Linux kernel is modified, the phone is actually an emulator and the "hardware" is modified... you can't trust anything in the hands of an attacker, and trying to hide things from them using slieght of hand is foolish: I'll just log the final network traffic and work backwards (which for many or even most kinds of credentials is something that can be trivially automated) instead of trying to slog forward from the output of a static analyer.

by shade23 10y ago

BoorishBears 10y ago

Stuff in native code (for example, XOR'd keys) is also marginally more difficult to access. It won't protect you from someone actively attacking your app, but it makes you less likely to get hit by people running automated scraping on apps for keys. At the end of the day it's all security by obscurity and the real answer is proxying calls or TVMs to limit what individual keys can do, but it doesn't hurt not to be the lowest hanging fruit either.

skybrian 10y ago

How does using an enum help? You still have a string literal in your code. Shouldn't that be easy to find?

saurik 10y ago

All of your "solutions" still involve having the keys on an untrusted computer: the one in my hand; it isn't correct enough to say it is "easier to just assume that everything you wish to keep private will be visible"... it absolutely fundamentally doesn't work to put something sensitive in the hands of the attacker, even momentarily. For people who just can't grok this, imagine some incredibly trivial to pull off scenarios: your app is modified, the Java virtual machine is modified, the Linux kernel is modified, the phone is actually an emulator and the "hardware" is modified... you can't trust anything in the hands of an attacker, and trying to hide things from them using slieght of hand is foolish: I'll just log the final network traffic and work backwards (which for many or even most kinds of credentials is something that can be trivially automated) instead of trying to slog forward from the output of a static analyer.