Good morning.

I will plunge right in.

Today's issue is all about securing secrets.

sorry -- hi, Paul!

It strikes me that the best approach is to get the secrets from the cloud and store them to SharedPreferences.

what sort of "secrets" are you referring to? API keys?

Is is possible for someone to grab an apk and use that to invoke the debugger and obtain data?

This for a Play Store (production) apk.

Yes, API keys.

is it possible to grab an APK? sure

is it possible to invoke a regular debugger? probably, at least on an emulator

I understand perfectly about obtaining the APK. It is running it in the debugger that I question.

they might have to repackage the APK with the debuggable flag set to get the debugger to work on production hardware

what do you mean by "obtain data"? read your files? intercept your Internet communications? something else?

Intercept network traffic.

unless you are using SSL with certificate pinning, they do not even need the APK for that

just use a proxy (Charles, mitmproxy, etc.)

SSL is taken for granted. No plain text on the web.

SSL alone is insufficient, as the attacker can use a proxy that provides you with a fake certificate

SSL with certificate pinning, or at least CA validation, prevents this

however, if you assume that the attacker *also* has access to the APK, they can just disable your pinning logic

rolling all the way back to your original concern: if the API keys are on the device, somebody can get to them

how many speed bumps are in the way will vary

Where does production key signing come into play?

in terms of what we are discussing, it doesn't

your signing key is used for determining if some APK is a valid update to an existing installed APK

When you say "on the device" do you include just in memory or do you mean on device stroage?

primarily, I mean in device storage

bearing in mind that if the attacker has the APK, they can always modify your app to persist whatever they want

IOW, you need to treat your APK as being as open as a Web page and its associated JavaScript

while it's not as easy to access the contents of the APK as it is to do File > Save As... in a browser, it's far from impossible

and while it's not as easy to modify the contents of an APK file as it is to edit plain-text HTML/CSS/JS, it's far from impossible

OMG. What do companies like Google do with their apps?

you would have to ask Google

Or you with yours?

on the whole, they tend to need authentication

and so the user is involved

personally, I don't use API keys in apps, other than for crash logging

IMHO, apps should not be directly accessing third-party services that require API keys

that stuff should be hidden behind *my* server

my attitude on this subject is not widely held

but, that's typical for me

:-)

What you say generally has resonated for me but I fear my app cannot exist for years if I do not use API keys.

to some extent, though, this all rolls back to Tim O'Reilly's line: your issue is not piracy, but obscurity

it is relatively unlikely that anyone is going to bother attacking your app to try to abscond with API keys

Our app will be obscure for quite a while. Give me some time to build a server based infrastructure. :-)

right -- so you need to decide whether "relatively unlikely" is sufficient or not

This would be the case.

using something like DexGuard (to encrypt the API keys), or your download-the-keys-and-store-locally approach, are sufficient "speed bumps" that you may be fine

assuming that the API keys get used in Java, vs. the manifest

in the manifest case, I think DexGuard still helps, but the download approach won't work

Definitely not the manifest.

Dexguard is something to look intol.

it's not cheap (750 USD last I looked, which was a while ago), and serious attackers aren't deterred by it

it's another speed bump

in this game, it's the old "I don't need to out-run the bear that's chasing us -- I just need to out-run *you*" scenario

Since I have you to myself so far, let me bounce my approach off you, if you don't mind. ($750 with no guarantee is not exciting me)

Good analogy.

My current thinking to solve my polling issue is to use the Android device (as a server) and send push notifications to the FCM servers. So far this works but has the very ugly detail that I have to supply the server key.

I haven't worked with GCM/FCM in a few years

for upstream messages, you need the server key?

Which means I have to do due diligence to secure the server key.

Usually a cloud server sends requests to the Google Cloud Messaging servers. In my approach, each device running the app will do this, when necessary.

One request can handle multiple devices.

And this totally avoids polling.

Sending requests to the Google servers does need the server key.

It is provided as an authorization header in an HTTP request.

Still with me?

more or less

OK

When we last talked I was struggling with how to be battery nice but still use polling, either as a deice service or via an external server.

yes

Then it occurred to me that in my app it is equally viable to send cloud messaging from the device directly, this taking on the external server role.

assuming you're happy with your approach, and assuming that Google is happy with your approach (i.e., you're not twisting FCM into knots), then I have no complaints

since FCM is free, the only reason why an attacker would want your FCM server key would be to send FCM messages to your app instances

That you see no danger signs is good news for me.

it's more that I'm out of date on FCM, and so I don't know whether your approach is good or bad

The other danger I saw was a malicious attacker using the server key to flood google servers.

sure, but now you're not only assuming an attacker (piracy vs. obscurity), but particular motivations behind obtaining the key

DDOS attack, but I would think Google can handle such maliciousness.

worst-case, they'll ban your server key

And tell me to get it out of the app.

Implicitly if not explicitly.

that would be a side-effect of the ban

right

I can live with that while living in obscurity.

But I will plan on upgrading to a real server at some point.

Sooner if the app has any traction.

fwiw.

that's one of the keys: recognize when you're cutting corners, and have a clear plan for how *not* to cut those corners when you have the resources to clean it up

of course, that implies "the resources to clean it up" comes along with "has any traction"

which is a business issue, more than a technical one

I certainly hope so, and expect so.

Correct.

a lot of the whatever-as-a-service stuff is designed to make development expedient for the early going

As are the tutorials and samples.

fwiw, I think Firebase is a technology that Google is betting heavily on for and that you would be wise to address it in your book.

I'll let somebody else handle that

I doubt they will use your book to put it in. :-)

OK, I'm ready to get back to work. As always, thanks for your wisdom, comments and advice. Have a great day.

you too!