目前我們有一個J2EE系統中實現大部分的OWASP十大安全措施的設備/用戶，目前該應用允許用戶與存儲在用戶/密碼組合登錄數據庫。驗證基於單個URL請求
我必須映射到/*一個Java過濾器檢查會話，會話屬性存在，以確定用戶的登錄狀態。
好了，終於在這裏的問題是：我們正在與製造商的設備時一定事件發生時通過GPRS發送URL請求的公司整合，此URL到我們的系統的鏈接。
我會（不妥協的安全）喜歡認證這個'設備'，它不可能發送設備的任何信息，所以一個請求需要被認證，沒有人應該能夠'重放'該URL
我不知道這是否可能沒有某種相互認證。我想到了一個需要檢查的IP地址白名單，但是網絡不斷地改變IP地址，而設備仍然是「未知的」。請告知任何想法？
PS：我的臨時解決方案是一個例外添加到我的過濾器，但這不是長期的，完全沒有安全感。 （SSL也不是選項）
您可以讓設備用私鑰簽署請求（包括唯一請求標識符）。然後，服務器可以檢查簽名是否有效，並且只有在它接受/接受請求時才能接受/回答。
請求ID可以用來確保這些請求不會被重播。對請求ID使用簡單的計數器意味着很容易檢查給定的標識符是否已被使用（即，如果請求正在被重播）。
主要問題是，無論設備包含哪些驗證信息，如果他獲得設備，第三方都可以使用該信息。
所以主要的問題是（a）你想要認證什麼（它應該是設備本身還是它的所有者或設備的位置或者......）和（b）設備可以支持哪些功能 - 什麼類型它的設備是什麼，它可以在操作方面做什麼。
如果設備可以嵌入智能卡或加密令牌其目的是爲了保持私鑰和抵制提取的嘗試則數字簽名將工作的偉大。
如果設備可以擁有受保護的內存但不能執行加密操作（並且不能嵌入智能卡），那麼我可以考慮預先計算的一次性密碼列表，每個設備都是唯一的。服務器將擁有全局列表的副本，並在使用列表後從列表中刪除密碼。
嗨尤金，我想使它儘可能通用，所以例如，如果我添加設備的功能，如果讓手機可以使用相同的用例（來賓登錄的受保護頁面），它會很酷。因此編寫一個非常特定於設備的解決方案對我來說也不是最合適的 – epoch
@epoch手機既可以保護存儲器（大多數情況下）也可以執行加密操作，因此它們不是問題。這是特定的設備，可能是一個問題。所以我認爲你會得到幾種解決方案，每種功能都有一種解決方案。 –
+1 - 某種數字簽名可能有幫助。請注意，如果將私鑰嵌入到設備中，可能會對其進行反向工程。如果所有設備共享相同的密鑰，這一點尤其糟糕。 – Qwerky
謝謝，好吧，我現在知道，在最糟糕的情況下，如果我們真的需要，設備可以接收，但它不是最優的。我不完全理解你的答案，我理解requestID/counter，但不知道如何簽名。它引導我進入谷歌會議，我唯一能找到的就是oAuth。你能解釋一下約阿希姆嗎？ – epoch
@epoch數字簽名是使用存儲在設備上的私鑰進行的（並且希望它是不可提取的）。會話ID可以是一個不斷增加的數字，它將被簽名。服務器將保留給定設備的最後使用的會話ID（基於設備的標識符和簽名）。 –