https://kotlinlang.org
Join Slack
Not really Kotlin related, but how bad is it to make these values public? <https://github.com/pan780...
# android
m
d
mg6maciej: 
<string name="default_web_client_id" translatable="false">288164734372-e6srsdkb53id69lgkendti7anv1bhcm9.apps.googleusercontent.com</string>
This looks like part of a server-to-server communication key. It’s probably not an issue unless there’s a client secret and a token somewhere else in the app though.
m
Some of the values are used for Android-to-google-services communication.
Like analytics or reporting a crash.
d
Yeah, that’s what it looks like for some of the values, but that id in particular is almost certainly a server-to-server key (it has the same format as the key I use for my automated apk uploader).
Without spending more time to look and see how it’s used and if the other pieces of information are there (the server secret) I don’t know if it’s actually an issue though.
r
That is definitely an issue - I don't know about Google specifically, but most apis of this sort contractually oblige you to not make your api keys public. Checking them into public source control is generally a pretty bad idea.
Worst case scenario: Someone finds the api key, uses it for malicious stuff, the malicious stuff gets traced back to you, the api key owner.
m
But in case of these values, they are (as I understand it) embedded in the APK, so you could get them from any app using firebase / google play services.
r
True, that's one of the uglier points of Android development. But scraping an apk for api keys is still harder than building a bot that crawls github for api keys, so the risk is way lower.
m
I know you could not reuse api key for google maps - the map would render blank, because you have to sign app with the same certificate if developer added SHA in console.
But in case of firebase crash reporting for example, I'm able to send any crash without issues from an app signed with different certificate.
r
Yeah if the api checks the certificate, it's not as bad. But yes that example is exactly why you should keep api keys secret.
m
Can't keep them secret if they are in client code 😉
d
I don’t think the crash reporting is a particularly large concern from a security standpoint— it’s a worst just going to pollute your data with unrelated stack traces. More worried about people being able to access their google account to some degree. I did notice that file was generated, but I don’t know where the source is from.
m
The source is google-services.json from downloaded from https://console.firebase.google.com
r
@mg6maciej That's why you try to keep them out of client code as well as you can. Web frontends for example often use an own backend server to proxy the api calls through, so the api key doesn't get leaked through javascript.
m
@dalexander It might be. Just imagine two popular apps competing. Flood the other developers with crashes looking real on certain devices and they will spend time buying these devices and trying to figure out, what's wrong. Your team in the meantime adds features which are requested by users of both apps.
✅ 1
Or you can destroy analytics for the other app by continually sending events that show the least used feature is used the most, so devs concentrate on improving that feature. 🙂
d
I mean, if you wanted to create a bunch of bad analytics or crashes I would guess that basically all apps are susceptible to being decompiled and played with to create noise? But for maps the “sign this with the same key used to sign the apk” seems to make me think it’s less likely than I previously thought. (a little off topic at this point though).
3 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by