使用HMAC保護REST服務

Question

我一直在閱讀：http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

這是一篇非常棒的文章。我在我的思想有一個問題是，這一步（在文章的後半部分）：

4. (OPTIONAL) The only way to protect against 「replay attacks」 on your API is to include a timestamp of time kind along with the request so the server can decide if this is an 「old」 request, and deny it. The timestamp must be included into the HMAC generation (effectively stamping a created-on time on the hash) in addition to being checked 「within acceptable bounds」 on the server. 
5. [SERVER] Receive all the data from the client. 
6. [SERVER] (see OPTIONAL) Compare the current server’s timestamp to the timestamp the client sent. Make sure the difference between the two timestamps it within an acceptable time limit (5-15mins maybe) to hinder replay attacks. 

如果時間戳必須發送，這意味着它必須在兩個客戶端上的散列和服務器，所以必須使用相同的確切時間。現在，這意味着我必須以純文本或加密的形式發送日期，可能作爲標題值。它是否正確？因爲如果它很簡單，那麼重放攻擊者不能輕易修改日期到可接受的範圍內（用於驗證目的）......所以我們可以加密日期，但這意味着哈希和加密數據都在使用只是一起加密所有的數據。

我的評估是否正確，或者是否有辦法包含安全的日期？還是必須在這種情況下加密？

謝謝。

Answer 1

HMAC是消息認證碼。這意味着如果你有一些消息M，你可以用消息和你的密鑰K生成V = HMAC（M，K）。記住，只要你保持K祕密，其他人就不能生成相同的V除非試圖猜測K.如果K足夠大，這是不可行的。

這也意味着您在M中包含的所有內容都不能在沒有V變化的情況下更改，因爲M和K在HMAC中都使用。因此，如果您包含時間戳，則必須確保它包含在HMAC計算中。如果攻擊者試圖修改時間戳，HMAC生成的V將會不同 - >您可以檢測到該嘗試並放棄該請求。

HMAC給你「真實性」，這意味着你可以知道它是否來自知道祕密密鑰的人。加密有些不同：它給了你「保密性」，意味着沒有人知道祕密密鑰就可以閱讀信息。請務必記住，加密不會賦予您真實性，因爲攻擊者只需更改加密消息中的隨機位即可。爲了保密和真實，您必須使用HMAC以及加密。

如果您不需要保密，請不要加密您的數據，因爲這會浪費CPU週期並使系統變得更加複雜而無法獲取任何內容。