Documentation states:
A purchase token is a string that represents a buyer's entitlement to
a product on Google Play. It indicates that a Google user has paid for
a specific product, represented by a SKU
and
Product ID - A unique, human readable ID for your product. Product IDs
are also called SKUs in the Google Play Billing Library.
As it is human readable I believe we can share SKU publicly (ex. in deeplinks).
Do we leak anything for hackers in that case or should we hash SKU?
As it is human readable I believe we can share SKU publicly (ex. in deeplinks).
Yes you can use them wherever you like, even if the product is only accessible by who bought it or have permissions to see it.
As you say, it is public, therefore not a secret and does not have any authorization capabilities.
Do we leak anything for hackers in that case or should we hash SKU?
No need to hash the SKU once it is public information that by itself cannot allow an hacker to have access to the purchased product. The hacker will need to have access to the purchase token and maybe other credentials to be able to access the product in the same way as the one who purchased it.
Before I go please allow me for a quick alert...
It may be seen as obvious but the purchase token must be considered as a secret, therefore it must be kept safe at all times, but this is not an easy task to achieve.
Please keep in mind that any tokens you have inside your app source code are easily extracted with reverse engineer techniques as I point out in this blog post:
Oh and did I mention already that in the case of mobile apps their binaries may be reverse engineered with tools like the Mobile Security Framework despite some techniques you may have employed to protect the secrets in your mobile app at run-time or to hide them from being reverse engineered from your binary?
As I point out on that blog post more advanced users can also use reverse engineer techniques to extract tokens at runtime with tools like the Mobile Security Framework. More tools can be found by searching on google for dynamic instrumentation tools.
Is the following approach necessary and/or best practice?
In my client call a back end server end point getRandomString with a sign in token to uniquely identify the user.
The server generates a random string and adds it to the user's list of available random strings
The client uses this random string as the developer payload.
When I come to verify the purchase token on the server I check that the developer payload is one in the users "random string" array.
If it's in the list, remove it, and validate the purchase, otherwise decline validation.
I can't find much in the way of guidance on this either in Google Docs, or on SE or posts seem to be from 5 years ago.
Is the above approach the right way to go. And also, is using developer payload actually necessary?
I think I've identified the source of the confusion on Developer Payload now. Years back when I was coding with InAppPurchasing developer payloads was an additional parameter in the launchPurchaseFlow function, but the new Billing Library with its launchBillingFlow does not support the developer payload any more. It is apparently now classed as a legacy field. See here for example. And in this Google post, we have confirmation:
Hi
The field developerPayload is a legacy field, kept to maintain the compatibility with old implementations, but as mentioned on Purchasing In-app Billing Products page (https://developer.android.com/training/in-app-billing/purchase-iab-products.html), this field isn't always available when completing tasks related to In-app Billing.
And since the library was designed to represent the most updated development model, we decided to don't support developerPayload in our implementation and we have no plans to include this field into the library.
If you rely any important implementation of your in-app billing logic on the developerPayload, we recommend you change this approach, because this field will be deprecated at some point (or soon).
The recommended approaches is to use your own backend to validate and track important details about your orders. For more details, check the Security and Design page (https://developer.android.com/google/play/billing/billing_best_practices.html).
Thanks
I am in the early stages of scoping an app that targets a specific vertical market. It is not consumer orientated. The organisation developing the app has existing web-based products and established infrastructure for registering user accounts and billing for those products, and the app should inter-operate with these products. To that end, I have a few questions:
1) If the app that has functionality that can only be enabled from outside the app (for example, via a separate web site) and where the developer bills the user for doing this:
Q1. Can this App be distributed using Google Play?
Q2. Since enabling the functionality takes place outside of the app, does the developer have to use Google Play's payment system to bill for it?
2) If the app which allows a user to create an item of content on a separate web site, so that they can subsequently modify it on that site and be billed for doing so (eg, a bug tracking app that charges for creating a bug record on a site):
Q3 Does this count as an in-app purchase and require use Google Play's payment system to bill for it?
Where can I find definitive statements from Google on these scenarios? I am only finding material that relates to consumer applications where the purchasing and billing scenario is fairly simple.
I cannot shed much light on the potential "thou shalst not have any payment methods beside me" aspect of your question, but as per the technical side, the following aspects come to my mind.
Q1: Technically, the app could either be free on GP and use other payment methods, or it could use the Licensing Validation service.
Q2: The only secure way of deploying Google Play Licensing is to perform all integrity checks on your own secure server. The app could request the GP LVL info and pass it to your server. You could use the GP LVL user ID (an obfuscated binary app-specific byte string) to identify the user and negotiate with your app any password details you may want to implement. Of course, in this scenario, I would expect the user to feel like he already payed so the registration on the server side should be smoothly integrated. If an "enabling"/"authentication" step is additionally required on the server side, I'm not so sure I'd use the GP LVL.
Q3: You could use GP IAB V3 consumable in-app purchases for this (or V2 subscriptions but it sounds more like a per-item payment). Again, this is only secure if you generate a per-purchase developerPayload for the buy Intent on your server and validate it when the app looks at the user's purchases. Validation again must take place on your server, or else you'll have to include your app's public key in your app, which is a major step towards your app getting cracked.
In general, if you have a user management of your own which is to be used, it is important to know that the GP info is relatively anonymous (LVL: obfuscated, IAB V3: no info in the direction of the app at all). So a reliable, use-case oriented binding between "your" accounts and the GP experience would be key here, I'd say.
I'm using version 3 of the in-app billing API. I have a single, managed, non-consumable item. I have not released this feature in my app yet, so I want to decide on the purchase payload contents before there are any purchases.
From "Security Best Practices":
Set the developer payload string when making purchase requests
With the In-app Billing Version 3 API, you can include a 'developer
payload' string token when sending your purchase request to Google
Play. Typically, this is used to pass in a string token that uniquely
identifies this purchase request. If you specify a string value,
Google Play returns this string along with the purchase response.
Subsequently, when you make queries about this purchase, Google Play
returns this string together with the purchase details.
You should pass in a string token that helps your application to
identify the user who made the purchase, so that you can later verify
that this is a legitimate purchase by that user. For consumable items,
you can use a randomly generated string, but for non-consumable items
you should use a string that uniquely identifies the user.
When you get back the response from Google Play, make sure to verify
that the developer payload string matches the token that you sent
previously with the purchase request. As a further security
precaution, you should perform the verification on your own secure
server.
Rightly or wrongly, I have decided not to take the "further security precaution" of setting up a server to perform purchase verification. And I do not store my own record of the purchase -- I always call the billing API. So is there really any reason for me to do this payload verification? The verification API itself certainly verifies the identity of a user before reporting an item as purchased, and if an attacker has compromised a device (either the app or the google play API), I don't see any benefit of doing an additional check on the user's identify on the device where it can easily be circumvented. Or is there a reason to do this that I'm not thinking of?
If you don't keep a record there is no way to verify that what you get is what you sent. So if you add something to the developer payload, you can either trust that it is legitimate (which is a reasonable assumption if the signature verifies), or not trust it completely and only use it a reference, but not for validating license status, etc. If you store the user email, for example, you can use the value instead of asking them to enter it again, which is slightly more user friendly, but your app won't break if it is not there.
Personally, I think that this whole 'best practices' part is confusing and is trying to make you do work that the API should really be doing. Since the purchase is tied to a Google account, and the Play Store obviously saves this information, they should just give you this in the purchase details. Getting a proper user ID requires additional permissions that you shouldn't need to add just to cover for the deficiencies of the IAB API.
So, in short, unless you have your own server and special add-on logic, just don't use the developer payload. You should be OK, as long as the IAB v3 API works (which is, unfortunately, quite a big 'if' at this point).
You should pass in a string token that helps your application to identify the user who made the purchase...
If your application provides its own user login and identity, which is different from what Google accounts the phone is connected to, then you would need to use the developer payload to attach the purchase to one of your accounts that made the purchase. Otherwise someone could switch accounts in your app, and get the benefit of purchased stuff.
e.g.
Suppose our app has login for userA and userB. And the phone's Android google account is X.
userA, logs into our app and purchases life membership. The purchase details are stored under google account X.
userA logs out, and userB logs into our app. Now, userB also gets the benefit of life membership, as android google account is still X.
To avoid such misuse, we will tie a purchase to an account. In the above example, we will set developer payload as "userA" when userA is making the purchase. So when userB signs in, the payload won't match to signed in user (userB), and we will ignore the purchase. Thus userB can't get benefits of a purchase done by userA.
There is also another approach to the developer payload handling. As Nikolay Elenkov said it is too much overhead to require user ID and setting additional permissions for user profile to your app, so this is not a good approach. So let's see what Google says in the latest version of TrivialDrive sample app in In-App Billing v3 samples:
WARNING: Locally generating a random string when starting a purchase and
verifying it here might seem like a good approach, but this will fail in the
case where the user purchases an item on one device and then uses your app on
a different device, because on the other device you will not have access to the
random string you originally generated.
So the random string is not a good idea if you are going to verify the purchased item on another device, but still they don't say this is not a good idea for verifying the purchase response.
I would say - use developer payload only for verifying the purchase by sending a random unique string, save it in preferences/database and on the purchase response check this developer payload. As for querying the inventory (in-app purchases) on Activity start - don't bother checking developer payload since that might happen on another device where you don't have that random unique string stored. That's how I see it.
It depends how you verify the developerPayload. There are two scenarios: remote verification (using server) and local (on device).
Server
If you're using a server for developerPayload verification it can be arbitrary string that can be easily computed on both the device and server. You should be able to identify the user who has performed the request. Assuming every user has the corresponding accountId, the developerPayload may be computed as combination with purchaseId (SKU name) like this:
MD5(purchaseId + accountId)
Device
developerPayload shouldn't be user email. A good example why you shouldn't use email as payload is Google for Work service. Users are able to change their email associated with the account. The only constant thing is accountId. In most cases email will be OK (e.g. Gmail addresses are immutable at the moment), but remember to design for future.
Multiple users may use the same device, so you must be able to distinguish who's the owner of the item. For device verification developerPayload is a string that uniquely identifies the user e.g.:
MD5(purchaseId + accountId)
Conclusion
Generally the developerPayload in both cases may be just the accountId. For me it looks like security through obscurity. The MD5 (or other hashing algorithm) and purchaseId is just a way to make the payload more random without explicitly showing that we're using id of the account. The attacker would have to decompile the app to check how it is computed. If the app is obfuscated even better for you.
The payload doesn't provide any security. It can be easily spoofed with 'device' approach and without any effort seized in 'server' checking. Remember to implement signature checking using your public key available in the Google Publisher account console.
*A must-read blog post about using account id instead of email.
In the Google IO video about IAB v3 given by the author of the trivial drive sample himself, this was briefly addressed towards the end of the video. It's to prevent replay attacks, e.g. attacker sniffs the traffic, steals the packet containing a successful purchase, then tries to replay the packet on his own device. If your app doesn't check the identity of the buyer via the dev payload (ideally on your server) before releasing the premium content (also ideally from your server), the attacker will succeed. Signature verification can't detect this since the packet is intact.
In my opinion, this protection seems ideal for apps with online account connectivity like clash of clans (payload comes in naturally since you have to identify users anyway), especially where hacking compromises multiplayer gameplay with far reaching effects other than a simple localized case of piracy. In contrast, if client side hacks on the apk can already unlock the premium content then this protection is not very useful.
(If the attacker attempts to spoof the payload, the signature verification should fail).
Late 2018 update: The official Google Play Billing Library intentionally does not expose the developerPayload. From here:
The field developerPayload is a legacy field, kept to maintain the compatibility with old implementations, but as mentioned on Purchasing In-app Billing Products page (https://developer.android.com/training/in-app-billing/purchase-iab-products.html), this field isn't always available when completing tasks related to In-app Billing.
And since the library was designed to represent the most updated development model, we decided to don't support developerPayload in our implementation and we have no plans to include this field into the library.
If you rely any important implementation of your in-app billing logic on the developerPayload, we recommend you change this approach, because this field will be deprecated at some point (or soon).
The recommended approaches is to use your own backend to validate and track important details about your orders. For more details, check the Security and Design page (https://developer.android.com/google/play/billing/billing_best_practices.html).
I struggled with this one. Since a Google Play account can only own one of any "managed" item, but could have several devices (I have three), the above comment from somebody that you sell a "per device" won't work... they'd be able to put it on their first device, and no others ever... If you buy a premium upgrade, it should work on all your phones/tablets.
I despise the notion of getting the user's email address, but I really found no other reliable method. So I grab the 1st account that matches "google.com" in the accounts list (yep, a permission to add to your manifest), and then immediately hash it so it's no longer usable as an email address but does provide a "unique enough" token. That's what I send as the Developer Payload. Since most people activate their device with their Google Play id, there's a good shot all three devices will get the same token (using the same hash algorithm on each device).
It even works on KitKat with multiple "users". (My developer id is on one user, my test id on another, and each user in their own sandbox).
I've tested it across six devices with a total of 3 users and each users devices have returned the same hash, and the different users all have distinct hashes, satisfying the guidelines.
At no point am I storing the user's email address, it's passed straight from the code to get the account names to the hash function and only the hash is saved in the heap.
There's probably still a better solution out there that respects users privacy even more, but so far I haven't found it. I'll be putting a very clear description of how I use the users Email address in my privacy policy once the app is published.
This often responds to a product definition (Your application).
For example for the case of subscriptions. Will the same user be able to use the subscription on all the devices he / she has? If the answer is yes. We did not check the payload.
For consumables. Suppose a purchase in your application gives you 10 virtual coins. Will the user be able to use these coins on different devices? 4 on one device and 6 on another?
If we want to work only on the device that made the purchase we have to check the payload for example with a self-generated string and locallly stored.
Based on these questions we have to decide how to implement payload check.
Regards
Santiago
I am using Android Licensing as described here:
http://developer.android.com/guide/market/licensing/index.html
(...to verify that my customers for my android app have actually payed for the app.) My app has a server component on the web, and for extra safety I'm doing the license validation on this server.
It all works okay. Now, to my problem. Since each new user ties up resources on my central server, I'm actually kind of reluctant to have non-paying users. I have seen some evidence of users continuing to use the app after having gotten a refund (per the normal 15-minute grace period).
To curb this behavior, it would be great if there was some way to map the payment of users at Google Checkout, to actual users in my system. Is this possible?
The ResponseData that I receive from the android license server contains a field called "userId", but this doesn't seem to correspond to any information in Google Checkout. (See http://www.androidadb.com/source/skylight1-read-only/GoogleLVL/src/com/android/vending/licensing/ResponseData.java.html for the definition of ResponseData.)
Is it possible to determine which payment in Checkout maps to which app installation?
As I currently understand it, the userId is obfuscated even on a per-app basis such that you can uniquely identify users per app but not figure which user it is nor whether the same user bought another app.
But I'm not sure you really need to identify these customers based on userId. If you have a server running anyway, the best way to protect your app is to have your server check the licence.
App -> Server: Give me a new nonce
Server -> App: Here is a secure random nonce
App -> Licence Service: Check user licence with this secure random nonce
Licence Service -> App: Signed licence response including repetition of nonce
App -> Server: Check licence signature with secret key (only on server)
Server -> App: Reject, or provide random token for access, etc
In this scenario, you won't authenticate users even if they mess with your LVL checking code.
However, you may of course introduce vulnerabilities after step 6 if you don't watch your step. Still, if you're currently using the standard LVL code and App-side licence check with the secret key stored in your app, changing to a mechanism as sketched above would be a huge improvement (there's even a script to remove standard LVL checking code from apps).