There's a developer interested in purchasing one of my apps (the only one that actually have users), meaning I would need to send him the original source code, the keystore and request Google for a transfer following this link: https://support.google.com/googleplay/android-developer/answer/6230247?hl=en
The issue is: all my apps use the same certificate from the same keystore.
So my question is: Would it be possible for the new developer to hijack any of my other apps?
I believe that the answer is "No. A device would allow another apk signed with the same certificate and with the same package name to update on the device, but Google Play wouldn't allow the developer to upload another app with the same package name as any of my other apps".
But I'm not sure on that and I would like further tech details on it.
As I said, the other apps I have are not important and I could just as well unpublish them. But I rather not, and even if I do, the question is still valid.
ps.: yeah, now I've learned that I should have 1-certificate per app.
The package name of your application is unique in the Play Store. It is how devices (and the Play Store) identify your application, and thus must be unique and cannot be changed. Android will not allow your users to install two applications with the same package name.
However, giving your keystore to another developer is still risky. The Play Store employs two gates when updating an application:
First, you must have access to the account that owns the application.
Second, you must have an APK signed with the correct keystore
By giving someone access to your keystore, you remove one of the two security checks. If the new owner of the application where to gain access to your developer account, they could re-publish the other applications as well. There's also the risk of this new owner selling the keystore and application to someone else in the future who might do the same thing.
Theoretically if your account is secure, then your other applications are also safe from hijacking.
Whether this risk is acceptable is up to you.
They could sign an APK and encourage your existing users to sideload it. When sideloading, the app isn't going to be able to know if it came from you or them. But the Play store itself won't let them upload an app that you haven't transferred to them.
Normally, part of the agreement when the buyer buys and app that using a key used by other apps would include a small snippet that the buyer must protect the key. This agreement would be bilateral anyways, since you could in theory hijack their users by sideloading a signed APK.
Would it be possible for the new developer to hijack any of my other
apps?
No way in the world its possible for him to do anything to any other of your apps unless you give him your keystore.
Your keystore is the key to all your applications and you should never share it with anyone. Having an app signed with your keystore in my developer account would never ever let me do anything to your own apps.
Anybody can have apps publish in plays store with different keystores.
Related
I have read the Docs for a few times but I'm still confused with the following question.
I have a few applications, published in Play Market under one account. All apps are signed with different keys.
I have decided to share data between them (AccountManager, ContentProvider with "signature" permission). Now I want to reset release certificates for all my applications, so I can sign all my applications with the same new key.
Is it possible for me? What should I do to have my already-published applications signed with a new common key?
Please, do not respond with theories! I already have enough.
Please share your precious experience with this kind of issue if you had one.
It is impossible to change signing certificate after publishing an app, or even after installing it.
It is enforced both by Google Play and also by each Android device.
So the ways you can share data between your apps is either by making the content provider public (very unsafe) or via a dedicated server endpoint that will serve both apps.
Another way is to republish your apps under a different package name, this time all with the same certificate, and also publish an update to the old apps that will show a "sorry, you'll need to replace this app with a new one" message to the users and give a link to the new app in Google Play.
With my experience you have to create a new jks file and change the package name, when you publish the apk on google play store.
Before being able to publish an Android App on Google Play it needs to be signed with a release key. Its said to be for security. When generating the key one has to enter a password.
What is all the fuss about, here?
Let me ask, what would happen if my release key got stolen/copied. Assume somebody could even manage to use that key to sign apps of him/herself. What bad would that mean?
I would argue, little to none, correct? (considering that my developer account/console credentials were not stolen too)
Maybe the biggest/ only risk would arrise if somebody elses app signed with the stolen release key would become able to more directly access data of my app (on the users devices).
They can grab your APK (publicly readable on all Android devices), modify it (e.g., add malware), sign it, and distribute it. Assuming that they bump the versionCode, anyone who tries installing their hacked version of your app will succeed, as from Android's standpoint, it is a valid upgrade. If the hacker can obtain your credentials for your distribution channel (e.g., compromise your Google account for the Play Store), they can ship their update to all of your users.
Or, they can create their own separate APK and sign it with your signing key. Now, your app and theirs are signed by the same key. That opens up other attack avenues:
If you used android:sharedUserId, they can get at all of your app's files on internal storage, which are normally protected from other apps (outside of rooted devices)
If you used permissions with a signature protectionLevel, their app can hold those same permissions and perhaps interact with your app in ways that you were only expecting your own suite of apps to use
Apple App Store allows publishing update to an application even when certificate lost and recreated but Google Play Store does not allow it.
Using same bundle id is fine for publishing an update of application to Apple App Store, so a new certificate could be used while publishing the update of the application.
So, why Google Play Store does not allow it? Is it a security weakness to allow it? Or Google Play Store is exaggerating about security and unnecessarily require same certificate?
Apple App Store allows it
But Google Play Store does not allow it
It has little to do with the Play Store. Android does not allow it, for security reasons. Malware authors would love the ability to replace an existing app with their malware-injected replacement. Requiring a matching signature is one of the ways that Android prevents this.
It's simple, Apple Certificate can be generated only by the owner of the account (or the hacker who got access to it). Also if the certificate is revoked the owner will get an email on this matter => not a big problem for security.
For Android, anybody who has a little knowledge about Android, can generate a keystore, find the app package name, and there you go, he/she could upload an update to your app => huge security problems.
On the other hand, as a developer is your responsibility to generate these keys/certificates and deliver them to your client and specifiy to your client that they are really important and they should be stored in a safe place. That's how I roll :D
I'm thinking about buying an existing android app from another developer. He has signed other apps not included in the sale with the same signing key as those included in the sale. What if any are the implications of sharing or duplicating the key and us both having a copy so we can update our owned apps? My main concern is can he update my newly purchased app without my permission or access to my developer account or vice versa?
There's a great article/video on how to do an acquisition at Phandroid. It does briefly address the idea of the signing key, but more from the seller's perspective. Regardless, I don't think it will be the worst thing in the world as while he could make a new signed APK of "your" app, he should not be able to publish it to Google Play after it's been transferred to your Google Account. He could try to distribute it through other means, but I wouldn't sweat it too much, especially if you're getting the conditions of the sale in a good contract.
Besides releasing a 'rogue' version of the app, another thing to note is that if the app is using signature permissions or sharedUserId, they could make another app that could potentially access and change data in the original app (via content providers, remote services, etc.) Even if the app is using neither of those, you might decide to add something in the future.
I am currently having an Android application developed by an outside third party. We are at the point where we are ready to implement/test In-App purchasing, but in order to proceed with that we must upload the application to the market first (so we can make the In-App Purchase ID's). In order to upload to the Market, you must sign the application with a non-debug key.
My questions are:
What is the best way to go about this and maintain the privacy of my keystore?
Can the keystore be changed later without affecting functionality of the app?
What is a good back-and-forth process that would make this work, assuming I will not be coding the In-App purchasing myself?
It seems the best way to test the app is to have the vendor upload it to Market under a different package name and using a certificate that you and this vendor share. This would be the debug version of the app, which would not be advertised.
After testing and debugging are complete and you're ready to release the production version, you'd have your vendor deliver you the unsigned APK to you with the final package name, and you would upload it to Android Market using your certificate, which you never share with the vendor.
The keypair used for signing must remain unchanged, otherwise you can't update existing application in Market. Consequently right approach is that the developer gives you an unsigned APK and you sign it locally, then submit to Market.
As Bruno Oliveira suggested in another answer, for debug purposes you can create an application and sign it with the key shared between you and developer. But in this case be ready to create and submit a brand new application for release for the reason I mentioned above.