12

I will be working with very sensitive data in an app. Obfuscation by my definition is not added security, it will only delay the cracker with finite time. Is it possible that Proguard does this so well it may be called added security?

What is most sensitive are some network calls. It will be hard to sniff the password because we will generate the password on both sides and check it's validity with timestamps. Problem is the app may be reverse engineered and the generate algorithm may be exploited.

It is not possible to keep the algorithm locally in a file because with a rooted phone the cracker may be able to retrieve it. It does not work to download the algorithm from the server because the same problem applies here, if the cracker reverse engineer the app he/she will be able to see where the algorithm is taken from.

Any input on how to proceed is greatly appreciated!

Edit

What I am trying to protect is the generate algorithm so the cracker may not send a lot of data to our server.

Simon Zettervall
  • 1,764
  • 1
  • 15
  • 31
  • Secure against _what_? What specific attacks are you trying to prevent? – SLaks Jul 15 '13 at 15:43
  • You have answered your question in the first row: "Obfuscation by my definition is not added security" please mark as solved and delete it :) –  Jul 15 '13 at 15:47
  • @matheszabi "Is it possible that Proguard does this so well it may be called added security?" – Simon Zettervall Jul 15 '13 at 15:56
  • @SimonZettervall nope, Any plain obfuscation is 0 for me at least There are some payed app, which will not only obfuscate, but it will make "your string" to a function call , which return the same buy you can search and find it very easy the "your" string, need to do an XOR or other bit manipulation. Those slow down a bit the hack method, but not really at least for me. Android is unsecure, thats't . In ioS you have to read the binary at least. If somebody write a code to lock a locket, than others can open it. How much time needed and what device that is other question. 100% security is myth –  Jul 15 '13 at 16:14
  • @SimonZettervall: That is fundamentally impossible. Your server cannot tell the difference between your client and an attacker's client. – SLaks Jul 15 '13 at 16:20
  • Instead, you can utilize a shared secret from the user. For example, require the user to log in before sending requests, then apply server-side rate limiting per account. – SLaks Jul 15 '13 at 16:21
  • @SLaks That sounds like a promising approach, but still given a finite amount of time the cracker will find out the algorithm. I will consider what you wrote though and I thank you for the input. – Simon Zettervall Jul 16 '13 at 07:47
  • @SimonZettervall: Huh? Do you mean that the attacker can brute-force a user's password? If so: a) Not if you rate-limit failed logins. b) That user will still be rate-limited. – SLaks Jul 16 '13 at 19:37
  • @SLaks I meant that I want to protect the algorithm that is in the app. Applying throttling will of course not make it possible for the cracker to succeed, but will this person venture into the app and reverse engineer it then one could find the password to the server and send in a lot of false data. – Simon Zettervall Jul 17 '13 at 08:03

1 Answers1

18

Generally, You can make the crackers life harder. The harder you make it, the fewer will remain. Especially if the financial incentive is limited.

Your code obfuscation options are:

  • Use proguard, it does a good job, not perfect of course, but good
  • Use DexGuard, which can make reverse engineering even harder, like by encrypting strings, or detecting code tampering
  • Write critical parts in C

Regardless of code obfuscation, make your network protocol also hard to mess around with: encrypt and sign messages, make sure messages can not be repeated (by using time or a sequence), and authenticate the client

Don't save on disk any clear texts that are sensitive.

yoah
  • 7,180
  • 2
  • 30
  • 30