Office Hours — Today, March 14

Thursday, March 9

Mar 14
8:50 AM
Mark M.
has entered the room
Mark M.
turned on guest access
8:55 AM
Paul R.
has entered the room
9:00 AM
Paul R.
Good morning.
I will plunge right in.
Today's issue is all about securing secrets.
Mark M.
sorry -- hi, Paul!
Paul R.
It strikes me that the best approach is to get the secrets from the cloud and store them to SharedPreferences.
Mark M.
what sort of "secrets" are you referring to? API keys?
Paul R.
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.
Mark M.
is it possible to grab an APK? sure
is it possible to invoke a regular debugger? probably, at least on an emulator
Paul R.
I understand perfectly about obtaining the APK. It is running it in the debugger that I question.
Mark M.
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?
9:05 AM
Paul R.
Intercept network traffic.
Mark M.
unless you are using SSL with certificate pinning, they do not even need the APK for that
just use a proxy (Charles, mitmproxy, etc.)
Paul R.
SSL is taken for granted. No plain text on the web.
Mark M.
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
Paul R.
Where does production key signing come into play?
Mark M.
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
Paul R.
When you say "on the device" do you include just in memory or do you mean on device stroage?
Mark M.
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
9:10 AM
Mark M.
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
Paul R.
OMG. What do companies like Google do with their apps?
Mark M.
you would have to ask Google
Paul R.
Or you with yours?
Mark M.
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
:-)
Paul R.
What you say generally has resonated for me but I fear my app cannot exist for years if I do not use API keys.
Mark M.
to some extent, though, this all rolls back to Tim O'Reilly's line: your issue is not piracy, but obscurity
9:15 AM
Mark M.
it is relatively unlikely that anyone is going to bother attacking your app to try to abscond with API keys
Paul R.
Our app will be obscure for quite a while. Give me some time to build a server based infrastructure. :-)
Mark M.
right -- so you need to decide whether "relatively unlikely" is sufficient or not
Paul R.
This would be the case.
Mark M.
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
Paul R.
Definitely not the manifest.
Dexguard is something to look intol.
Mark M.
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
Paul R.
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.
9:20 AM
Paul R.
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.
Mark M.
I haven't worked with GCM/FCM in a few years
for upstream messages, you need the server key?
Paul R.
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.
9:25 AM
Paul R.
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?
Mark M.
more or less
Paul R.
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.
Mark M.
yes
9:30 AM
Paul R.
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.
Mark M.
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
Paul R.
That you see no danger signs is good news for me.
Mark M.
it's more that I'm out of date on FCM, and so I don't know whether your approach is good or bad
Paul R.
The other danger I saw was a malicious attacker using the server key to flood google servers.
Mark M.
sure, but now you're not only assuming an attacker (piracy vs. obscurity), but particular motivations behind obtaining the key
Paul R.
DDOS attack, but I would think Google can handle such maliciousness.
Mark M.
worst-case, they'll ban your server key
Paul R.
And tell me to get it out of the app.
Implicitly if not explicitly.
Mark M.
that would be a side-effect of the ban
right
Paul R.
I can live with that while living in obscurity.
9:35 AM
Paul R.
But I will plan on upgrading to a real server at some point.
Sooner if the app has any traction.
fwiw.
Mark M.
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
Paul R.
I certainly hope so, and expect so.
Correct.
Mark M.
a lot of the whatever-as-a-service stuff is designed to make development expedient for the early going
Paul R.
As are the tutorials and samples.
9:40 AM
Paul R.
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.
9:40 AM
Mark M.
I'll let somebody else handle that
Paul R.
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.
Mark M.
you too!
Paul R.
has left the room
10:00 AM
Mark M.
turned off guest access

Thursday, March 9

 

Office Hours

People in this transcript

  • Mark Murphy
  • Paul Reilly