Android Inapp Billing - What Are Really Nonces For?

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 com

Solution 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

Solution 2:

You should be saving the generated nonces before sending them. Android apps can crash or be shut down at any point so in general everything should be saved.

The reason for using nonces is to prevent replay attacks. I´m far from qualified to answer whether to using the nonce is neccesary or not but I assume it's there for a reason.

Solution 3:

Imagine your user purchases an item for lets say $100. Your app is notified that there is payment data available, the app requests the data and the AppStore answers with a PURCHASE_STATE_CHANGED. The user records the message (!) from the AppStore and keeps it save.

Later, the user fakes a notification to your app, telling it that payment data is available (anyone can fake that, as this notification is not signed). The app thinks "oh, hey, maybe I just crashed and lost all information about a purchase that my user just made!? Let's see what the AppStore has to say". So it requests data from the app store. The user interrupts that request and sends the previously recorded message to your app. The app sees the message, verifies it and finds that it is valid (because it's signed and all). So the app will give you another valuable $100 item. And another. As often as the user replays the recorded message. Therefore called: a replay attack.

There is however one thing that prevents such an attack: the nonce. If your app sends a nonce in its request for payment data, it expects to receive that same nonce in the PURCHASE_STATE_CHANGED reply. As a nonce is only used once, you can't replay previously recorded messages, because they won't match with the nonce that was used in the request.

Solution 4:

"The nonce acts like a salt on the transaction, similar to how *nix systems store passwords. The nonce is used to add entropy to the value that is encrypted with your key, largely eliminating the chance that two transactions are encrypted and result in the same signature, and other similar cryptographic attacks."

see the answer by queso