We at my company work with outsource on our Android application. If the outsource provider has the full source code, is it safe to also provide him with the certificate and its credentials we signing the application's APK with?
There are 3 steps of security for Android apps:
Source code
.jks and credentials
Google console access
If you break all three, they can rework and reupload your app to Google Play Store.
Probably, it's bad idea to send them .jks and credentials.
And actually, why do they need that?
The release keystore you use to sign a APK will remain the same across its lifetime. If you are using the App Signing system, sharing the upload key is less risky, since your Developer console account credentials will remain with you, and you can reset that key.
Even if they have full access to source code, it is better to limit access to certificates and keys in order to avoid impersonation or misuse later, when they may not be working with you. You may also consider managing permissions for developer account users to ensure they can only modify what you allow them to.
Related
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
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.
What are all the conditions satisfied by the APK to upload in play store?
like debug release,signed apk,keystore generation.and please explain them how to do?
A release build. So you should ensure you are not polluting the logcat with your debugging statements. Usually this will automatically be flagged off for you but you may (as I often did) use different forms of debug logging (eg with the NDK) which will need explicit deactivation.
You will need to sign your APK also. You can generate a key and keystore offline with your development tools (i.e. Android Studio, can't remember about Eclipse but (How do I generate a "Keystore" for Google Play?) should work in that instance).
When you register an account on the playstore you need to upload your public key. You can associate about 20 (IIRC) keys with an app's GMS profile, although that is not strictly required to upload an app in general it is one of the great benefits of a Play Store account. See https://developers.google.com/android/guides/setup for more on that.
Then if you are seeking financial reward, either via advertisemnet or direct sales you will need to provide your address.
For this service and also, I suspect, for the purposes of identity verification, Google require a one off registration fee of a princely $25.
I just sold one of my Android apps via Apptopia. The selling process requires that I send the buyer my Android certificate key, used to sign the app.
I have several other apps which I'm not selling, that are signed using this same certificate.
Is is safe to send the key to the buyer? Is there any way they could mess with my other apps?
Thanks
I would not say it is safe, but. Given that they are getting access to your key, technically it makes them possible to generate packages that can be 'uploaded' in place of your other applications, but they still do not have acces to your developer console (I am assuming you are transferring your app out of your account), so that gives you a certain degree of safety.
I know it is late, but a good practice could be to sign your apps with separate certificates in the future (which has its own drawbacks too, in certain cases). See this.
I have to upload a new application, It's just the design that's a little different. Yesterday I generated the keystore file to sign application. Can I use the same?
You can use that keystore for any number of applications.
No need to generate a new keystore.
I'll make a counter argument to the consensus answer so far.
I agree that for most app authors most of the time, sharing the same keystore/certificate/password between your apps will work fine. The critical thing is to use "the same certificate throughout the expected lifespan of your applications" so the app can upgrade itself.
But I can think of one very good reason to have separate keystores for separate apps or families of apps. If you think you might ever want to sell an app to someone else for them to publish as an upgrade to the original, you'll have to share your one-and-only keystore and password with them to do so. Probably not a huge issue but a bit of worry to you and, perhaps, a due diligence issue to a big-enough buyer.
Also, I really don't read the same line in the documentation the same way as #ol_v_er does. I think the current line:
You should sign all of your apps with the same certificate throughout the expected lifespan of your applications.
(note the lack of a comma in the current version) is simply emphasizing that the 'lifetime' recommendation applies to all apps, not actually directing you to use the same certificate for all of your apps.
The official documentation tells us:
In general, the recommended strategy for all developers is to sign all of your applications with the same certificate, throughout the expected lifespan of your applications. There are several reasons why you should do so ...
https://developer.android.com/studio/publish/app-signing.html#considerations
So yes, try to sign all of your applications with the same certificate.
I want to add some clarification here, because this question and the answers provided lead to confusion for me. It is crucial to understand what a keystore actually is.
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. It has security implications, however. If your single alias is compromised, then all of your apps will have been compromised.
However, if you intend to sell the rights to your apps one day, then using the same alias for all of your apps may not be a good idea. However, using the same keystore, provided you use a different alias for each apk, may not necessarily be a bad option. I'm sure there is a way that you can move a certificate from one keystore to another, so that you can securely give the necessary keys for only that certificate to your buyer.
To make it very clear, a keystore is just that, a storage medium for keys. It plays no actual part in the process of signing an apk, but only serves to store the keys which are actually used to sign the apk.
References:
Understanding keystore, certificates and alias
https://www.digitalocean.com/community/tutorials/java-keytool-essentials-working-with-java-keystores
Of course! You can use the same keystore file as many times you want. It's always better to use the same keystore file for all the applications you develop. That will help if you want to update or modify the application. At that time you need to sign your application with the same key.
Recent Update
If you want to enrol in App signing by google you have to use new different key to sign your apk or bundle otherwise after uploading google console will give you error message saying
You uploaded an APK or Android App Bundle that is signed with a key
that is also used to sign APKs that are delivered to users. Because
you are enrolled in App Signing by Google Play, you should sign your
APK or Android App Bundle with a new key before you upload it
I do sign all my apps using the same certificate (keystore). This gives an advantage if i change my mind and want my apps to share their data.
As you might know Android identifies each app with an UID. If all your apps are signed by the same certificate you can request android to assign same user id more than one app and inturn make them run in a single process and share the data.
From android doc android:sharedUserId
android:sharedUserId
The name of a Linux user ID that will be shared with other applications. By default, Android assigns each application its own unique user ID. However, if this attribute is set to the same value for two or more applications, they will all share the same ID — provided that they are also signed by the same certificate. Application with the same user ID can access each other's data and, if desired, run in the same process