基於REST的API的安全性

我一直在尋找技術來保護在android/iphone應用程序或網站應用程序中使用的API。
我發現了一種我喜歡的技術，但不確定它是否是好的或者什麼是錯的（除了是一個長時間的過程）。
基於REST的API的安全性

處理（用戶側最初）：
首先一個鹽通過散列用戶口令創建的。
然後通過散列請求的URL（通過查詢字符串在末尾附加用戶名）和salt來創建簽名。
最後，通過散列用戶名和簽名來創建令牌。
令牌在標頭內傳遞給服務器（每次）。

第一請求：
第一個請求必須是驗證端點幷包括DEVICE_ID作爲查詢字符串。
在服務器上完成相同的處理（如上所述），並且如果令牌與用戶發送的令牌相匹配，則將device_id存儲在數據庫中，並將其分配給該用戶名以供將來參考（設備ID在請求中找到網址），並在此後用於驗證用戶名/設備。

所有後續請求：
在用戶端和服務器端現在爲每個請求與令牌是不同的，每次（如所請求的URL變化）的處理必須發生。
未包含代碼，因爲尚未編寫代碼。

來源

2013-01-15 Craig Taub

你不這樣做，你創建與鹽散列，而不是「通過散列創造鹽」。 –

@JakubKonecki好點猜測鹽應該是一個'鹽'，然後用密碼散列。 –

「salt」只是在散列字符串之前由服務器向密碼添加的一串祕密隨機字節。它可以防止相同的密碼（例如'passw0rd'）在任何地方產生相同的散列結果。這可以防止黑客使用彩虹表將密碼反轉回密碼。儘可能讓你的鹽儘量模糊，你甚至可以爲每個用戶名使用不同的salt值（但不要把它作爲用戶名，這太明顯了）。 –

您的身份驗證模型是共享的祕密身份驗證。在你的情況下，你的用戶密碼充當共享密鑰。你需要確保你有一個安全的方式提前獲得密碼給用戶和服務器。爲了簽署請求，您可以創建一條包含所有請求標頭和數據的消息。然後散列該請求。然後該散列（令牌）將與請求一起傳遞。服務器將在服務器上執行相同的簽名和散列處理，並確保令牌匹配。

在你的榜樣你的聲音就像你要創建這個僞碼令牌：

Token = hmac-sha1(Hash(Pasword + Salt) + RequestUrl + UserName)

你的方式是不壞，但我想你的方法比較亞馬遜的REST驗證模型和實施更緊密的版本他們詳細描述了什麼。 http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

及其履行情況：

"Authorization: AWS " + AWSAccessKeyId + ":" + base64(hmac-sha1(VERB + "\n" 
           + CONTENT-MD5 + "\n" 
           + CONTENT-TYPE + "\n" 
           + DATE + "\n" 
           + CanonicalizedAmzHeaders + "\n" 
           + CanonicalizedResource))

他們對包括已經離開了，包括但不限於某些領域很好的理由：

時間戳是防止重放攻擊。
內容-MD5是防止防止人與請求篡改數據（相關 POST並提出）

來源

2013-01-15 14:51:41 kampsj

非常好。另外，如果您需要更簡單的方法，則可以通過SSL（HTTPS）連接使用基本或摘要HTTP標準身份驗證。 – miguelcobain

基於REST的API的安全性

回答

相關問題