2012-05-09 32 views
5

是的,我已經閱讀了所有的文檔@ developer.android.com,我明白這一切都有一個基本的例外 - 它是什麼引入的。由於所有來自Google Play的訂單響應都由無法通過任何人訪問的私人密鑰簽名,並且正在通過配對公鑰進行驗證(在我的情況下,在外部服務器上,因此它對第三方人員也無法訪問),因此簡單地(幾乎)沒辦法欺騙。Android InApp帳單 - 什麼是真正的無用帳戶?

所有這些只是保護購買的多餘方式。更重要的是,文檔中沒有提到這種情況:

  1. 我購買了一件商品;
  2. 生成隨機數併發送給Google Play;
  3. 發生崩潰,所以我所有的已知的隨機數都丟失了;
  4. 我的應用程序重新啓動並從Google Play獲得回叫;
  5. ...並且由於沒有識別現時而拒絕此呼叫!

在上面描述的情況中,用戶爲物品付款並從未得到它,這是什麼可恥的。當然,我可以將隨機數存儲在某個文件中,並在應用程序恢復時重新讀取它,但它違反了所有隨機原則。恕我直言,有人只是說:「嘿,驗證過程太簡單了,讓我們隨意添加更多東西,它會變得更酷!」。 所以有人這樣做。或者,你是否會打開我的想法,我缺少一些其他用例?否則,我將從我的代碼中刪除整個隨機部分。

+0

如果採購的管理,記得總有恢復的購買能力,如果他們曾經1.需要一個新設備,2.必須在工廠重置設備。 – weston

+0

你是對的,我忘了他們,因爲我沒有,但它是如何與隨機連接? –

+0

只要你的「用戶支付一個物品,永遠不會得到它」情景是不是一個問題,如果你碰巧使用託管購買,所以沒有必要擔心在這種情況下失去隨機。我並沒有聲稱這是一個答案,只是一個評論! – weston

回答

2

你並不需要存儲的隨機數「到磁盤」考慮到一個應用程序崩潰。

當您的應用程序崩潰時,您將失去已知隨機數的列表。但是,當您的應用程序重新啓動並且您收到IN_APP_NOTIFY時,則必須在執行此操作時執行另一個GET_PURCHASE_INFORMATIONGET_PURCHASE_INFORMATION您將生成新的隨機數並將其添加到已知的隨機數列表中。

你必須記住的是,隨機數是每GET_PURCHASE_INFORMATION(它返回給你多個購買的物品),而不是每個被購買的物品的一個隨機數。

正如你說你已經實現了你自己的方式,以避免重放攻擊,但使用一個隨機數是一旦這種安全方法

+1

恩,謝謝,我認爲你已經達到了目標。當你不檢查其他獨特的東西時,Nonces應該被認爲是處理回覆攻擊的很多方法之一。即orderId在JSON(這是更好的恕我直言)。但在我的情況下,它們是無用的。 –

0

您應該在發送它們之前保存生成的隨機數。 Android應用程序可能會在任何時候崩潰或關閉,因此通常應保存所有內容。

使用隨機數的原因是prevent replay attacks。我很難回答是否使用隨機數是否必要,但我認爲這是有原因的。

+1

我將它們保存在內存中,將它們保存在本地磁盤上,讓其他人閱讀/僞造/不管。我不必擔心回覆攻擊,因爲正如我所提到的,非對稱密鑰足夠安全,確保我沒有任何人被欺騙。 –

+0

從安全角度來看,「在磁盤上」與「在內存中」沒有區別。如果您的手機已植根,則應用程序可以同時訪問這兩者。如果沒有根源,他們將不得不利用安全漏洞獲得訪問權限。 – richardwiden

+0

你想告訴你的用戶你_THINK_ _YOUR_方法是安全的_ENOUGH_? – richardwiden

0

想象一下,您的用戶購買了一個可以說100美元的物品。應用程序會收到通知,說明存在付款數據,應用程序請求數據,AppStore會以PURCHASE_STATE_CHANGED回答。用戶從AppStore記錄消息(!)並保存它。

稍後,用戶向您的應用程序發出通知,告訴它付款數據可用(任何人都可以僞造該通知,因爲此通知未簽名)。該應用程序認爲「哦,嘿,也許我剛剛墜毀並丟失了關於我的用戶剛購買的所有信息!」讓我們來看看AppStore的說明。所以它從應用商店請求數據。用戶中斷該請求並將之前錄製的消息發送到您的應用程序。該應用程序看到該消息,驗證它並發現它是有效的(因爲它已被簽名並且全部)。所以該應用程序會給你另一個有價值的100美元的物品。另一個。就像用戶重放錄製的信息一樣。因此稱爲:重播攻擊。

然而有一件事可以防止這種攻擊:nonce。如果您的應用在其付款數據請求中發送了一個隨機數,它希望在PURCHASE_STATE_CHANGED回覆中收到相同的隨機數。因爲隨機數只能使用一次,所以不能重放先前錄製的消息,因爲它們不會與請求中使用的隨機數匹配。

+0

這不完全是這樣的。您所推出的方案是可以的,但它仍然沒有顯示什麼是隨機的 - 我知道回覆攻擊這樣的問題,但我以其他方式處理它 - 我對Google Play響應非常滿意我的外部服務器,我在哪裏保存我的公鑰。更重要的是,爲了避免你提到的這種情況,每次我都會保存唯一的帶有簽名JSON的orderId - 它不能被僞造,因爲它已被簽名,並且保證唯一。我只是用相同的orderId忽略第二個味精。看起來隨便是真正無用的(甚至更多 - 正如我所說的那樣有害)。 –

0

「Nonce在事務上的行爲類似於salt,類似於* nix系統存儲密碼的方式,nonce用於將entropy添加到用您的密鑰加密的值,很大程度上消除了兩個事務被加密的可能性並導致相同的簽名和其他類似的加密攻擊。「

看到the answer by queso

相關問題