アプリへの API 呼び出しを保護するために API キー システムを実装したいと考えています。
私がうまくいくと思う方法は、アカウントごとに秘密鍵/秘密を持っていることです。各リクエストには、時間、アカウント ID、およびハッシュ (時間 + シークレット) が含まれています。
サーバーは、データベースからのユーザーの秘密を使用して同じことを実行し、クライアントが送信したハッシュに対してそれを確認できます。
これは合理的な方法ですか？総当たり攻撃にさらされていますが、秘密が長い限り（つまりuuid）、それほど問題にはならないと思います...
思い
誰でも同じ時間とハッシュで別のリクエストを送信し、それを受け入れてもらうことができます。
問題は、ナンス+ハッシュを再生できることです。実際の認証プロトコルには、少なくとも2つのメッセージが必要です。
Server Client
---->challenge --->
<----response------
たとえば、チャレンジはサーバーによって提供されるナンスである可能性があり、クライアントの応答はナンスを含むパスワードのハッシュになります。
残念ながら、これには状態が必要であり、RESTfulプロトコルの全体的な問題は、状態を維持する煩わしさを望まないことです。それでも彼らは認証したい...
したがって、実際には3つのオプションがあります。
オプション1：問題が存在しないふりをして、ステートレス「認証」プロトコルを使用します。これは、Cookieを使用するのと同じです。nonce + password-hashは、cookieほど安全ではありません。クッキーは盗まれたり、再生されたりする可能性があります。現在、Web全体がこれらのリプレイ攻撃に悩まされています。
オプション2：ステートレス通信方式に認証プロトコルを追加してみてください。ここでは、クライアントにナンスの代わりにUTCタイムスタンプを送信させることになります。タイムスタンプを使用すると、再生に対する防御が制限されます。明らかに、あなたの時計はクライアントの時計と同期されないので、サーバーはあるエラーマージン内のタイムスタンプを許可し、そのエラーマージンは認証プロトコルの再生マージンになります。認証メッセージはべき等ではないため、これはRESTに違反することに注意してください。べき等は、「攻撃者が正常に再生できる」ことを意味します。
オプション3：認証プロトコルをステートレスプロトコルにボルトで固定しようとしないでください。SSLを使用します。クライアント証明書を使用します。クライアントに文字列をダウンロードさせる代わりに、クライアントに証明書を生成させるか、キーペアをクライアントに提供することができます。これらはSSLを介して認証され、RESTレイヤーでは認証されません。SSLには多くの「オーバーヘッド」があります。これらのリプレイの問題に対処しているという理由だけで、軽量ではありません。
したがって、結局のところ、APIへのアクセスをどれだけ重視するかによって異なります。
サーバーには以下が含まれます:
クライアントが送信するもの:
クライアントがサーバーを呼び出すと、サーバーはパスワード ハッシュ (それ自体が認識している) + ランダム文字列 (クライアントを呼び出して GET で指定) のハッシュを作成し、それがハッシュ (クライアントを呼び出して GET で指定) と一致するかどうかを評価します。
「ノンス」（ランダムなもの）もサーバーに保存されている（パスワードハッシュ+ナンス）から秘密のハッシュを生成する1つの関数を作成することをお勧めします。次に、ユーザー名とパスワードを使用してサーバーを 1 回呼び出すことができるようにします。これにより、シークレット ハッシュが返されます。その後の呼び出しは、上記と同じ方法で、ユーザー名 + ランダム文字列 + (シークレット ハッシュ + ランダム文字列) のハッシュのみに依存しますが、シークレットは当時のパスワードでした。こうすれば、秘密が傍受されて取り消されても、パスは安全です。
そして明らかに、優れたハッシュ アルゴリズム: rot13 がなく、md5 だけでも問題があります。