1

私はこれを読んでいます：http ：//www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

本当に素晴らしい記事でした。私が考えている問題の1つは、このステップ（記事の後半）にあります。

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.

タイムスタンプを送信する必要がある場合、これは、タイムスタンプがクライアントとサーバーの両方のハッシュに含まれている必要があることを意味するため、同じ正確な時刻を使用する必要があります。さて、これは、日付をプレーンテキストまたは暗号化して（おそらくヘッダー値として）送信する必要があることを意味します。これは正しいです？なぜなら、それが明白な場合、リプレイ攻撃者は日付を許容範囲内に簡単に変更できないためです（検証目的で）...したがって、日付を暗号化することはできますが、それは代わりにハッシュと暗号化されたデータの両方が機能していることを意味しますすべてのデータを一緒に暗号化するだけです。

私の評価は正しいですか、それとも安全な日付を含める方法はありますか？または、このシナリオでは暗号化する必要がありますか？

ありがとう。

4

1 に答える 1

6

HMAC はメッセージ認証コードです。これは、メッセージ M がある場合、メッセージと秘密鍵 K を使用して V = HMAC(M, K) を生成できることを意味します。K を秘密にしておく限り、他の誰も同じ V を生成できないことに注意してください。ただし、K を推測しようとする場合を除きます。K が十分に大きい場合、これは実行不可能です。

これは、M と K の両方が HMAC で使用されるため、V を変更せずに M に含めるすべてのものを変更できないことも意味します。したがって、タイムスタンプを含める場合は、それが HMAC 計算に含まれていることを確認する必要があります。攻撃者がタイムスタンプを変更しようとすると、HMAC によって生成された V が異なります -> その試みを検出してリクエストを破棄できます。

HMAC は「真正性」を提​​供します。つまり、秘密鍵を知っている誰かからのものかどうかを判断できます。暗号化は別のものです。「機密性」が得られます。つまり、秘密鍵を知らなければ誰もメッセージを読むことができません。攻撃者は暗号化されたメッセージのランダムなビットを変更するだけでよいため、暗号化によって信頼性が得られるわけではないことに注意してください。機密性と信頼性の両方を確保するには、HMAC と暗号化を使用する必要があります。

機密性が必要ない場合は、データを暗号化しないでください。CPU サイクルが浪費され、システムが複雑になり、何も得られません。

于 2012-06-12T14:59:34.137 に答える