這是我的網站API的安全認證方案嗎？

Question

我目前正在爲我的教會與一些相當敏感的數據有關係的數據庫應用..

的應用程序是用Ruby on Rails的，

我們也期待它有一個iPhone應用程序擴展。

目前，我試圖找到驗證iPhone應用程序的用戶提供最佳的解決方案，這裏是一個解決方案，我想出了：

1. iPhone應用程序發出握手請求（通過SSL），返回一個帶有2個值的JSON字符串：api_key和api_secret。

2. 任何後續請求都附加了2個附加參數api_key和api_signature api_signature基本上是api_secret與用戶電子郵件一起散列以掩蓋祕密。

3. Rails應用程序通過散列在一起api_secret和用戶的電子郵件，並將其與通過簽名認證比較簽名..

4. 的應用程序得到它的數據:-)

5. 的api_secret無效並重新創建每2小時（所以如果黑客得到了它保持他們願意有一個有效的祕密2小時..）

聰明，因爲我認爲這是..我看到一個昭然若揭obvio我們的場景：

如果什麼黑客拿到API_KEY和反正api_signature的保持..

如果他們加上他們與那些他們在等什麼在我的所有obsfucation點PARAMS要求？

你會如何更好地執行此操作？

非常感謝！

Answer 1

我認爲你的問題是靜態簽名。

如果你look at how AWS這樣做（如果別人已經做得很好，我是不會重新發明車輪的粉絲），他們的簽名是從請求的所有參數中散列出來的，其中一個參數是強制的時間戳。

這很重要，因爲它意味着即使對相同數據的重複請求，簽名也會快速更改。強制時間戳也意味着您可以確保請求具有相對較短的有效性，假設客戶端和服務器上的時鐘不相距太遠。只要2個小時，我肯定不會擁有它 - 我會把窗口縮短到15分鐘。

把它看作公鑰和私鑰。您可以發佈公鑰（api_key），但只有客戶端和服務器才能知道私鑰。

私鑰不應該在請求中傳輸，並且傳送它的靜態哈希也不是很好 - 因此亞馬遜採取的做法。

如果您確實需要將私鑰傳輸到設備上，我會覺得在與api_key相同的有效載荷中傳輸私鑰是非常不舒服的，但您應該在此時接受安全專家的建議因爲我超出了我的深度，很高興承認它。

Answer 2

幸運的是，你的問題並不是唯一的，所以沒有必要重新發明任何東西。只需使用Digest access authentication。我不太瞭解Ruby on Rails，但我知道有support for it。您也可以使用ASIHttpRequest獲得爲iPhone實施的客戶端，因此您不必制定任何安全方案。