REST APIのHMACソリューション

Question

私はREST apisについていくつかのことを学ぼうとしています、そして私がいくつかの問題を抱えているトピックの1つはセキュリティです。

私は、php apiのウェブインターフェースとスリムフレームワークにangularjsを使用しています。私はいくつかの記事を読みました（私はこれが好きでした）このチュートリアルに従ってHMACの実装を開始しました（まったく同じ手順ではありません）。私のアプローチに重大なセキュリティ違反があるかどうか、またはこれを正しく行っていないかどうかを知りたいのですが。

AngularJSを使用しているので、クライアント側に保存するすべてのものが安全ではないことを知っています。私は、ユーザーが「新品同様の」マシンを持っていて、彼が何をしているか知っていると想定しています（おそらく、主要なapiユーザーでしょう）。私のより大きな懸念は、中間者と複製です。

（クライアント側）

ユーザーはユーザー名とパスワードを入力します。
彼のパスワードは暗号化され（sha256など）、グローバルとして保存されます。（彼のユーザー名はどこかに保存されています）
WebインターフェースがAPIに送信するすべてのリクエストでは、ユーザー名、タイムスタンプ、リソースへのパス、ランダム文字列（サーバーとクライアントの両方が認識している）を使用してメッセージが形成されるヘッダーにhmacハッシュが送信されます;ハードコードされています）、キーはパスワードハッシュです。

（サーバー側）

サーバーがリクエストを受信すると：

タイムスタンプをチェックします。
ユーザー名がDBに存在するかどうかを確認します。
変数（リクエストでも受信）のユーザー名、タイムスタンプ、リソースへのパス、およびランダム文字列（これはリクエストで受信されず、ハードコードされているだけです）を使用して、同じhmacハッシュを複製しようとします。キーには、指定されたユーザーの暗号化されたパスワードである、DBに格納されている値を使用します。

すべての検証がうまくいけば、ユーザーは単なる中間者ではなく、信頼できる人物になるはずです。

dst · Accepted Answer

あなたのアプローチにはさまざまな問題があります（順不同、おそらく完全なリストではありません）。

SSL/TLSなしでアプリケーションをデプロイしているようです。その場合、MITMは（安全な）クライアント側の実装をユーザーが選択したものに置き換えることができるため、クライアント側に依存することはできません。

SSLなしで安全なWebアプリケーションを作成する方法はありません。クライアントは安全でないチャネルを介してアプリケーションをロードするためです。アプリケーションがセキュアチャネルを介してデプロイされている場合（angularjsがオフラインデプロイメントをサポートしているかどうかは不明）、無視してください。

SSLを使用する場合、それはMITMおよびリプレイ攻撃から保護するため、おそらく他のすべての攻撃シナリオを軽減します。クライアント証明書を使用しない場合、問題になる可能性があるのは認証のみです。ただし、サーバーは適切に認証されているため（適切な実装を使用する場合）、通常はセッショントークンで十分です。
リプレイ攻撃から保護したいが、リクエストにはタイムスタンプのみを使用します。攻撃者が要求を十分に速く記録および応答できる場合、サーバーはその要求を有効と見なします。実際のデータによっては、これが問題になる場合と問題にならない場合があります。

この攻撃を防ぐには、リクエストカウンターを追加するか、最後のリクエストのタイムスタンプをサーバーに保存します（保存されているタイムスタンプよりも大きいタイムスタンプが必要です）。
実際のHMACに加えて、あなたはパスワードを塩漬けにするではありません。そのようにして、データベースアクセスを持つ攻撃者は、アプリケーションとユーザーのパスワードにとって致命的です。パスワードをソルトすることを強くお勧めします。

また、通常はパスワードを何度もハッシュして、ハッシュに対する辞書攻撃に必要なワークロードを増やします。
あなたが書いたものから、あなたがあなたのHMACにメッセージ/リクエスト内容を含めることは明らかではありません。しかし、私は、HMACが生成されたデータの整合性のみを検証するという事実を知っていると思います。
HMACには真にランダムなキーを使用しません。今日の計算能力を考えると、ハッシュは計算しやすいため、弱いパスワードはクラック可能なHMACにつながる可能性があります。複数のラウンドをハッシュすることは少し役立つかもしれません（そして攻撃が複数のユーザーに対するものである場合はソルトする）かもしれませんが、最後にブルートフォース防御をインストールすることが重要です（1時間あたりの不正なリクエストの最大数など、次にソースIPをブロックします）。

ただし、私は個人的には、ユーザーのパスワードに基づいてsoleyを信頼することはありません。

したがって、個人的には、独自の暗号をロールバックすることや、SSL/TLSを使用しないことをお勧めします。基本的には、クライアントが信頼するすべてのCAがMITMを認証できることを意味しますが、そのリスクは、悪意のあるWebアプリケーションをユーザーに配信したり、リクエストを再生したり、HMACの秘密をクラックしたりすることによってMITMが認証するよりもはるかに低いと思います。