The keystore and its password are used to sign the app that is then used by Android to identify the developer. If leaked, someone could update the concerned app on our behalf. Even if the person doesn't have access to our playstore account, they still could publish it somewhere else.
We see everywhere, "never lose it", "never leak it", etc. But what if I did? I cannot find the required steps to follow when they both, the keystore and its password, leak so I can protect our users and our app.
Even if I publish the same app with an other appid, how can I protect my users that are still on the old one? Is there some best practice here?
The JKS keystores are binary stores and its contents are encrypted using the password as a key. No one can access the contents without the password. The password is for protecting the contents of the store from illegitimate accesses and manipulation.
Since the keystore file is secured with a password, we have used the brute-force and the dictionary attack to crack the password of the keystore file in Ethereum wallets. Our results showed that the dictionary attack is more efficient to hack the keystore file than the brute-force attack.
Keystore file is stored and secured in Google play. Your APKs will be signed by Google Play with app signing key and published to users. Even if you lost your upload key you can contact with Google and you can update your application after validating your account.
A keystore is just a means to securely store the public/private key pair which is used to sign your Android apks. So yes, you can use the same keystore to sign multiple apks, without a problem. You can also use the same alias (each alias is a certificate) to sign multiple apks, and it will work.
Unfortunately there doesn't seem to be a great way to migrate an existing application to a new signing key. This is probably for the best, since the best practice remains to a) have a strong key and b) keep your private release key as private as possible. I found this article outlining a feasible (but rather user un-friendly way) to migrate from a 1024 bit to a 4096 bit key, which seems to fit your use case. Since you still have a valid signing key for the compromised app, you can attempt to migrate them away from it via update.
Unfortunately, there is no easy answer to this problem. As mentioned above, the most general solution is to create a new app, tell users to switch, and migrate the data over.
However, on Lollipop+, there is another possible solution. You can use upgrade keys to change the signing key of an app in place, which saves you the trouble of creating a second app or doing the data migration. Unfortunately, Play currently has no support for this, so it's only really an option for off-market apps, and users on Kitkat are out of luck.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With