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:
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.
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
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