Question

YES, I’ve read all the docs @ developer.android.com and I do understand it all with one basic exception – what it was introduced for.

Since all order responses from Google Play come signed by inaccessible-by-anyone private key and are being verified by paired public key (in my case on external server, so it is also inaccessible for third person) there’s simply (almost) no way to spoof.

All those nonces are just redundant way of securing the purchases. And what’s more, the docs say nothing about the situation, when:

1. I purchase an item;
2. Generate nonce and send it to Google Play;
3. Have a crash, so all my known nonces are lost;
4. Have my app restarted and got callback from Google Play;
5. …And reject this call due to having not recognized nonce!

In described above situation user pays for an item and never gets it, what it’s shameful. Of course I can store nonces in some file and re-read it when my app gets back, but it violates all the principles for nonces.

IMHO someone just said “Hey, the verification process is too simple, let’s add something more with randomness, it’s gonna be way more cool!”.
So someone did.

Or, would you open my mind to some other use-case am I missing?
Otherwise I’m removing whole nonces part from my code.

Answer 1

You don’t need to store the nonce ‘to disk’ to account for an app crash.

When your app crashes yes you will lose your list of known nonces. However when your app restarts and you receive an IN_APP_NOTIFY you then have to do another GET_PURCHASE_INFORMATION when you do this GET_PURCHASE_INFORMATION you will generate a new nonce and add it to the list known nonces.

What you have to remember is the nonce is one per GET_PURCHASE_INFORMATION (which returns you multiple purchased items) not one nonce per item that is bought.

AS you’ve said you’ve implemented your own way to avoid Replay Attacks, but using a nonce is once such secure method