9

My application uses a number of API keys and URLs that I can't allow users to see. I've been putting them directly in the code, sometimes embedded in the method that uses them and sometimes in a class called MyVals that stores commonly used strings and numbers.

e.g.:

public class MyVals {

    private LGVals(){}

    public static final String DB_URL = "https://mydb.dbprovider.org/";
    public static final String DB_Key = "klJF*(oh8iyhkkde";
    public static final String TableKey_UserList = "o9w6owifhayf98fnwihj";

}

Is this safe? Does it make a difference if I'm creating my APK with Proguard? What's the best practice for this?

Scott
  • 3,663
  • 8
  • 33
  • 56
  • Best practice are use-based accounts. Everything els can be extracted from your app. – Robert Jul 17 '14 at 14:15
  • 1
    The problem is that even if you would obfuscate your strings, at some point your app also needs to be able to revert this obfuscation. If someone is determined to figure out these credentials it is possible to figure them out, no matter if they are inlined or stored in a properties file or somewhere else. If you have control over the design of that web-service you should require the user of your app to register and retrieve an individual access key from the server instead of distributing a single "master key". – tiguchi Jul 17 '14 at 14:15
  • no. never. if you are protecting anything significant there is no safe way to put the key on the device. – G. Blake Meike Jul 17 '14 at 14:53
  • Re: significance, this isn't a mobile banking app or anything. Mostly I'd like to prevent vandalism, although it's possible user behavior could be read as well. But if you don't put a key on the device, even obfuscated, where do you put it? How do you give the app authorization to pull private data? The one suggestion I've seen, a private server, doesn't fix the problem since the key to that must be on the device! – Scott Jul 17 '14 at 16:10
  • There are several close votes on the grounds that this is opinion-based. I don't agree - in strict crypto terms, either it is safe to do this, or it is not. – DNA Jul 17 '14 at 17:15

2 Answers2

5

It is absolutely not safe to embed sensitive strings into your code. Proguard obfuscates the class and method names, but any defined strings remain completely unchanged. Here's an example from an app that I've run through Proguard. You can see that the method and class names are obfuscated, but the strings (as they must be) are unchanged.

Here is the original code:

public void shutdown() {
    if (logger.logDebug()) {
        logger.logDebug(LOGTAG, "Queuing shutdown message ...");
    }

    queueMessage(new BaseMessage(true));
}

And the obfuscated code, easily obtained by JD-GUI:

  public void c()
  {
    if (c.logDebug())
      c.logDebug("MsgRouter", "Queuing shutdown message ...");
    a(new a(true));
  }

If you embed sensitive data in a String in your app, it can and will be decompiled.

AWT
  • 3,657
  • 5
  • 32
  • 60
-5

No, this is not secure.

You should at least put the Information into the SharedPreferences.

But still, anybody with root-access could read them.

PKlumpp
  • 4,913
  • 8
  • 36
  • 64
  • Just to complement the other question, Proguard does not touch in literal Strings, it will only change it's name like "DB_Key" to "A". – Pozzo Apps Jul 17 '14 at 14:05
  • 4
    WTF!? Properties files makes it even easier for the users to extract it. Just extract the file and open it with a text editor. – Robert Jul 17 '14 at 14:13
  • I was thinking the same thing. If you write this stuff to SharedPreferences, anyone with root access could easily just read that plain text file off your device. – AWT Jul 17 '14 at 14:17
  • 1
    Exactly @Robert I don't see how this is more secure. Android is not a servlet-container where you can put credentials of web-apps in config-files. Anyone with root access to the phone can read those, no matter if in source-code or in files. Even encrypting strings is not secure because the key has to be stored somewhere too.. it only makes it harder. – Blacklight Jul 17 '14 at 14:21
  • sry I mixed this up with something else. I didn't see it was about android. – PKlumpp Jul 17 '14 at 14:28