Mar 14 | 8:50 AM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Mar 14 | 8:55 AM |
Paul R. | has entered the room |
Mar 14 | 9:00 AM |
Paul R. |
Good morning.
|
Paul R. |
I will plunge right in.
|
Paul R. |
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?
|
Paul R. |
This for a Play Store (production) apk.
|
Paul R. |
Yes, API keys.
|
Mark M. |
is it possible to grab an APK? sure
|
Mark M. |
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
|
Mark M. |
what do you mean by "obtain data"? read your files? intercept your Internet communications? something else?
|
Mar 14 | 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
|
Mark M. |
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
|
Mark M. |
SSL with certificate pinning, or at least CA validation, prevents this
|
Mark M. |
however, if you assume that the attacker *also* has access to the APK, they can just disable your pinning logic
|
Mark M. |
rolling all the way back to your original concern: if the API keys are on the device, somebody can get to them
|
Mark M. |
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
|
Mark M. |
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
|
Mark M. |
bearing in mind that if the attacker has the APK, they can always modify your app to persist whatever they want
|
Mar 14 | 9:10 AM |
Mark M. |
IOW, you need to treat your APK as being as open as a Web page and its associated JavaScript
|
Mark M. |
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
|
Mark M. |
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
|
Mark M. |
and so the user is involved
|
Mark M. |
personally, I don't use API keys in apps, other than for crash logging
|
Mark M. |
IMHO, apps should not be directly accessing third-party services that require API keys
|
Mark M. |
that stuff should be hidden behind *my* server
|
Mark M. |
my attitude on this subject is not widely held
|
Mark M. |
but, that's typical for me
|
Mark M. |
:-)
|
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
|
Mar 14 | 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
|
Mark M. |
assuming that the API keys get used in Java, vs. the manifest
|
Mark M. |
in the manifest case, I think DexGuard still helps, but the download approach won't work
|
Paul R. |
Definitely not the manifest.
|
Paul R. |
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
|
Mark M. |
it's another speed bump
|
Mark M. |
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)
|
Paul R. |
Good analogy.
|
Mar 14 | 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
|
Mark M. |
for upstream messages, you need the server key?
|
Paul R. |
Which means I have to do due diligence to secure the server key.
|
Paul R. |
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.
|
Paul R. |
One request can handle multiple devices.
|
Paul R. |
And this totally avoids polling.
|
Mar 14 | 9:25 AM |
Paul R. |
Sending requests to the Google servers does need the server key.
|
Paul R. |
It is provided as an authorization header in an HTTP request.
|
Paul R. |
Still with me?
|
Mark M. |
more or less
|
Paul R. |
OK
|
Paul R. |
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
|
Mar 14 | 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
|
Mark M. |
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.
|
Paul R. |
Implicitly if not explicitly.
|
Mark M. |
that would be a side-effect of the ban
|
Mark M. |
right
|
Paul R. |
I can live with that while living in obscurity.
|
Mar 14 | 9:35 AM |
Paul R. |
But I will plan on upgrading to a real server at some point.
|
Paul R. |
Sooner if the app has any traction.
|
Paul R. |
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
|
Mark M. |
of course, that implies "the resources to clean it up" comes along with "has any traction"
|
Mark M. |
which is a business issue, more than a technical one
|
Paul R. |
I certainly hope so, and expect so.
|
Paul R. |
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.
|
Mar 14 | 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.
|
Mar 14 | 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. :-)
|
Paul R. |
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 |
Mar 14 | 10:00 AM |
Mark M. | turned off guest access |