49
我正在設計一個網站，其中將有一個移動伴侶（僅限初始iPhone）。該網站將是一個ASP.Net MVC 3應用程序。我還會有一個ASP.Net Web API站點（MVC 4）來向iPhone應用程序提供服務。 iPhone應用程序將擁有自己的表單來捕獲用戶的用戶名和密碼，並將其發送到JSON標頭中的Web API。驗證從移動（iPhone）應用程序到ASP.Net Web API的請求（我的設計請求提供反饋）
我想從一開始就考慮安全性，而不是一想到以後。 我不是一個安全專家。我已經做了大量的研究，以瞭解其他人如何從Web服務處理移動應用程序客戶端的身份驗證。我想我已經想出了一個體面的解決方案，不涉及到第三方oAuths。
我會非常感謝您提供任何意見，建議，批評和一般的WTF。 :)
我最大的擔憂是：
- 確保到Web API的調用被授權
- 最大限度地減少重放攻擊的風險（因此時間戳在下面的調用）
iPhone應用程序將如下開發：
兩個字符串被硬編碼到iPhone應用程序中（每個用戶的值相同）：
- 應用程序ID
這是一個用來識別客戶端在訪問網絡API（在iPhone，Android，Windows phone的，等等）的類型的字符串。 - 應用程序的散列鹽
這是一個字符串，用於對用戶不可知的請求進行鹽散列。
兩個字符串存儲在iPhone應用程序的本地數據庫（唯一的每個用戶的值）：
- API用戶訪問令牌
這是提供給客戶一個字符串（令牌）通過Web API驗證成功後，允許客戶端訪問Web API，而無需在每個請求中發送用戶名和密碼。 - 用戶散列鹽
這是用來鹽哈希針對建立用戶帳戶的請求字符串。
iPhone將在以下幾個方式調用網絡API：
API方法：創建帳戶
客戶端發送：
- 新帳戶數據（用戶名，密碼，名字，姓氏等）。
- 應用程序ID
- UTC時間戳
- UTC時間戳+應用程序ID的哈希加鹽與應用的散列鹽
API返回：
- 新用戶的散列鹽
這裏的想法是，在創建帳戶時，我可以使用應用程序的硬編碼鹽，因爲如果鹽（通過反編譯或其他方式）出來，它不是一個巨大的安全風險。
但是，對於訪問和修改用戶數據的方法，我將使用僅由該用戶擁有的salt，因此攻擊者不能使用它來模擬其他用戶。
API方法：獲取帳號
（用於獲取用戶的散列鹽用於在網站上創建的，但尚未同步iPhone上的帳戶會發生這種情況，當用戶嘗試。登錄iPhone和iPhone會檢測到它沒有該用戶名的記錄。）
客戶端發送：
- 用戶名
- 密碼（散列與應用程序的散列鹽）
- 應用程序ID
- UTC時間戳
- 哈希UTC時間戳+應用程序ID與應用程序的散列鹽醃鹽
API返回：
- 現有用戶的散列鹽
API方法：登錄（認證）
客戶端發送：
- 用戶名
- 密碼（散列與用戶的散鹽）
- 應用ID
- UTC時間戳
- 哈希UTC時間戳+應用程序ID與用戶的散列鹽鹽漬
API返回：
- API用戶訪問令牌
API方法：任何命令（即創建後，更新個人資料，獲取信息等）
客戶端發送：
- 命令數據
- API用戶訪問令牌
- 應用ID
- UTC時間戳
- 散列UTC時間戳+應用程序ID + API用戶訪問令牌用戶散列鹽鹽漬
你的問題是幫助我喬，因爲我試圖做同樣的事情。我有一個問題 - 當用戶創建一個帳戶時，你發送用戶名和密碼而不用散列它們。看起來很好，因爲它只是一次。但是，如果手機試圖登錄已創建的帳戶，則可以使用應用鹽對用戶名和密碼進行哈希處理。這真的比再次發送它更好嗎？我的意思是，我知道這樣會好一點，但是發送兩次未反映的信息並不比發送一次更不安全。或者我錯過了什麼？ – 2012-10-19 12:45:16
@AndrewBSchultz，你是對的，我沒有加密那個第一個電話。由於它是SSL，並且由於最初的通話只發生一次，所以暴露風險可以忽略不計。 – Stoop 2012-12-08 00:50:39
任何次數發送「unhash」信息都是不安全的。但真正的意義在於，整個API都受到SSL保護，因此所有傳輸都是加密的。將用戶的鹽從服務器傳遞到客戶端是值得懷疑的。這是什麼意思呢？除此之外，這意味着你在多個地方計算密碼哈希值，當你發現現有的密碼哈希算法被破壞（並且最終你會）時，很難升級你的密碼哈希算法。只需傳遞用SSL和SSL保護的用戶名和密碼，然後讓服務器執行哈希。 – Craig 2013-06-24 15:18:01