10

I develop android game using cocos2d-x. For android release, it contain this fields in proj.android/gradle.properties:

# uncomment it and fill in sign information for release mode
#RELEASE_STORE_FILE=file path of keystore
#RELEASE_STORE_PASSWORD=password of keystore
#RELEASE_KEY_ALIAS=alias of key
#RELEASE_KEY_PASSWORD=password of key

Entire project (including this file) is placed on BitBucket in private repository. So I have four questions:

  1. Is it safe enough for regular developer at all?
  2. If someone get access only to this file (and APK from Google Play), what can he do?
  3. If someone get access to this file and keystore (and APK from Google Play), what can he do?
  4. Is there a way to store it separately from git project?
Improve this question

2 Answers 2

Reset to default
9
  1. Not really, no. As nbering said, it is very hard to remove it from git history if you ever want to share it. Git is also not really meant to hold this kind of information.
  2. Not much. The password only encrypts the key, so without the encrypted key, they can't really do anything.
  3. A lot. They can create a version of your app with malware inside it and pass it as yours. However, without access to your appstore account, they may not be able to publish it directly. This still allows them to distribute it in other ways, eg. through different appstores or using the web. If they do gain access to your appstore account, they can publish their malware version as an update and users would have no way of knowing.
  4. Yes and no. If you use manual builds, then you can just add the file into gitignore and distribute it in other ways. If you use autonomous builds, most git sites support special functionality for storing secrets.
Improve this answer
7
  • 2
    To the first point, note that there are bots out there scraping Git repos, including history, for any and all keys that might be of interest. If you (or anyone else) someday flip your Git repo to public, even after removing the keys from the current files, the keys in the history are going to be snapped up instantly.
    – ArrowCase
    Jul 5, 2018 at 17:19
  • If hacker can't do anything without keystore, how sharing password with someone can make a problem?
    – val - disappointed in SE
    Jul 5, 2018 at 18:24
  • @val I assume you are asking if the keystore is worthless without the password. It is the same consequence as losing something like a password hash... in theory it is secure, but it gives the attacker unlimited ability to brute force weak passwords. The keystore would probably be worse in lacking any of the mitigation present in a good password hash such as multiple rounds and salting. Using a very strong password (think > 32 random characters) would offer pretty serious protection... assuming the keystore encryption is actually strong.
    – le3th4x0rbot
    Jul 5, 2018 at 19:34
  • 1
    @val As long as you never slip up or otherwise compromise the key-store, then it does not really matter. The password was not really meant to be stored in the file anyway. The point was for you to enter it when you build a release version of your app, so if you got for example a virus, the password would be in your head or on a piece of paper and could not be stolen. PS: Another use of the password can be to store it in separate backup from the key-store, so if it gets compromised, there is still the password.
    – Peter Harmann
    Jul 5, 2018 at 22:43
  • 2
    @val Probably not worse than having no password at all on the keystore. Definitely weakens the security model a bit, for example what if you were to accidentally commit the keystore to git as well or something, now all of the magic is there. The stuff about protecting from a system compromise is probably ambitious... you have to type that password in sometime! Honestly, I would never download your app if I knew you took any risks about storing secrets in git or generally argued with security best practices. What app is this again?
    – le3th4x0rbot
    Jul 6, 2018 at 3:05
3

Why not?

It’s all a matter of risk. My main argument against is that if you ever want to share that repository with someone who shouldn’t have the password, it’s really hard to remove the password from the git history. You need to rewrite all history to that point. So you’d have to rewrite all the commits, or squash to lose the history that contained the password. And you probably won’t remember to do that, so it’s safest just to leave them out.

Avoid Committing Secrets

To avoid storing secrets in git, I usually add the secret file to .gitignore. Since someone might need to know what was in the now-missing file, leave something like a gradle.properties.example file, with the redacted fields as "CHANGEME" or something like that, so anyone using the file will know how to create gradle.properties.

If possible, substitute from environment variables, so that you won't need to use a .example file. I personally recommend a tool like direnv which allows you to create a git ignored .envrc file, which can be used to set environment variables on a per-project basis. It automatically loads the environment variables from the terminal when you enter the directory. This doesn't always work well with graphical tools though, since their environment variables will be taken from the environment they were launched from.

Some graphical IDEs do support a concept like "targets" or "workspaces", which understands that some configuration options are configured in files that are checked in to source control, and others are specific to the files on your computer.

What's the risk?

If someone got ahold of your signing key, and the password, they could sign a malicious copy of your application.

If they managed to submit this copy to the app store, your users may automatically receive the malicious copy, without any notice that it was changed. Their device would trust it, because it was signed by your key.

Even without an app store submission, they could possibly sign a copy of the application and side-load it onto a device where the app was already installed, which would still trust it because it was signed by the same key.

Improve this answer
4
  • You didn't answered what some bad people can do with that password/password+keystore. Also, how can I avoid doing it?
    – val - disappointed in SE
    Jul 5, 2018 at 13:08
  • I edited my answer to provide more detail.
    – nbering
    Jul 5, 2018 at 13:21
  • 5
    I want to add, that there is another risk - someday you can just lose password and/or keystore if it didn't stored in safe place. As a programmer, I've seen this couple of times, when you open old dusty project and didn't find it keystore.Oops, we have a huge problem with app update releasing.
    – ITurchenko
    Jul 5, 2018 at 15:02
  • Yes, there is risk associated with loss of keystores and their passwords. But having to get a new app ID for your application and get users to download it again is inconvenient... a malicious version of your app getting out may actually cause harm.
    – nbering
    Jul 5, 2018 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .