Вопрос по android – Android InApp Billing - для чего действительно нужны одноразовые номера?

5

Да, я прочитал все документы docs @ developer.android.com, и я все понимаю за одним исключением - для чего он был представлен.

Поскольку все ответы на заказы из Google Play подписаны закрытым закрытым ключом и проверяются парным открытым ключом (в моем случае на внешнем сервере, так что он также недоступен для третьего лица), просто (почти) нет способ подделать.

Все эти одноразовые номера являются просто избыточным способом обеспечения покупок. Более того, документы ничего не говорят о ситуации, когда:

  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!

В описанной выше ситуации пользователь платит за товар и никогда не получает его, за что ему стыдно. Конечно, я могу хранить одноразовые номера в каком-то файле и перечитывать их, когда мое приложение возвращается, но это нарушает все принципы для одноразовых номеров.

ИМХО кто-то только что сказал: «Эй, процесс проверки слишком прост, давайте добавим что-то еще со случайностью, это будет намного круче!». Так кто-то сделал.

Или, не могли бы вы открыть для меня какой-то другой вариант использования, который я пропустил? В противном случае я удаляю целую часть nonces из моего кода.

Только ваш & quot; пользователь платит за товар и никогда его не получает & quot; Сценарий не является проблемой, если вы используете управляемые покупки, поэтому не нужно беспокоиться о потере одноразовых номеров в этом случае. Я не претендую на то, что это ответ, просто комментарий! weston
Если покупки управляются, помните, что всегда есть возможность восстановить покупки, которые потребуются пользователям, если они когда-либо: 1. получат новое устройство, 2. должны сбросить настройки устройства до заводских. weston
Вы правы, я забыл о них, поскольку у меня их нет, но как это связано с одноразовыми номерами? Fenix Voltres

Ваш Ответ

4   ответа
2

ложения.

Когда ваше приложение падает, вы потеряете список известных одноразовых номеров. Однако, когда ваше приложение перезапускается, и вы получаетеIN_APP_NOTIFY Затем вы должны сделать другоеGET_PURCHASE_INFORMATION когда ты это делаешьGET_PURCHASE_INFORMATION Вы сгенерируете новый одноразовый номер и добавите его в список известных одноразовых номеров.

То, что вы должны помнить, это одноразовыйGET_PURCHASE_INFORMATION (который возвращает вам несколько купленных предметов), а не одноразовый номер за купленный товар.

Как вы уже сказали, вы реализовали свой собственный способ избежать повторных атак, но использование одноразового номера является одним из таких случаев.secure метод

Error: User Rate Limit Exceeded Fenix Voltres
0

saving the generated nonces перед отправкой их. Приложения Android могут аварийно завершить работу или быть закрыты в любой момент, поэтому в целом все должно быть сохранено.

Причиной использования одноразовых номеров являетсяпредотвратить повторные атаки, Я далек от квалификации, чтобы ответить, является ли использование одноразового номера необходимым или нет, но я предполагаю, что оно есть по какой-то причине.

Error: User Rate Limit Exceeded Fenix Voltres
Error: User Rate Limit Exceeded Fenix Voltres
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededTHINKError: User Rate Limit ExceededYOURError: User Rate Limit ExceededENOUGH?
0

& quot; Одноразовый номер действует как соль в транзакции, подобно тому, как системы * nix хранят пароли. зашифрованному вашим ключом, что в значительной степени исключает вероятность того, что две транзакции зашифрованы и приведут к одной и той же подписи, а также к другим подобным криптографическим атакам. & Quot;

увидетьответ на вопрос

0

что ваш пользователь покупает товар за, скажем, 100 долларов. Ваше приложение уведомлено о наличии платежных данных, приложение запрашивает данные, а AppStore отвечает с PURCHASE_STATE_CHANGED. Пользователь записывает сообщение (!) Из AppStore и сохраняет его.

Позже пользователь подделывает уведомление для вашего приложения, сообщая, что платежные данные доступны (любой может подделать это, так как это уведомление не подписано). Приложение думает "о, эй, может быть, я просто потерпел крах и потерял всю информацию о покупке, которую только что сделал мой пользователь !? Давайте посмотрим, что скажет AppStore. Поэтому он запрашивает данные из магазина приложений. Пользователь прерывает этот запрос и отправляет ранее записанное сообщение в ваше приложение. Приложение видит сообщение, проверяет его и находит, что оно является действительным (потому что оно подписано и все). Так что приложение даст вам еще один ценный предмет стоимостью 100 долларов. И другой. Так часто, как пользователь воспроизводит записанное сообщение. Поэтому и называется: повторная атака.

Однако есть одна вещь, которая предотвращает такую атаку: одноразовый номер. Если ваше приложение отправляет одноразовый номер в своем запросе данных о платеже, оно ожидает получить тот же самый одноразовый номер в ответе PURCHASE_STATE_CHANGED. Поскольку одноразовый номер используется только один раз, вы не можете воспроизвести ранее записанные сообщения, поскольку они не совпадают с одноразовым номером, использованным в запросе.

Error: User Rate Limit Exceeded Fenix Voltres

Похожие вопросы