3

プライベートデータを取得するためにクライアントが接続するWebサービスを設計しています。各クライアントには、自身を認証するためにパラメーターとしてWebサービスに送信される一意のIDと秘密鍵（サーバーによって生成される）があります。さらに、すべての通信はHTTPSを介して行われます。

また、秘密鍵をネットワーク経由で送信しないようにするために、HMAC-SHA256を使用することも計画しています。

しかし、これが厳密に必要かどうか疑問に思います。HTTPSはクライアントとサーバー間の安全なチャネルを提供するので、なぜそのチャネルを介して秘密鍵を送信するのが本当に気になるのでしょうか。

私が思いついた唯一の理由は、知識のない開発者が将来サービスを追加し、HTTPS以外の接続を拒否しない可能性があるため、秘密鍵をハッシュすることは、企業のソフトウェア開発の現実に対する一種の保険であり、余分な行ですあなたがそうするなら防衛の。

もっと重要なものが欠けていますか？これは、一部の攻撃ベクトルが利用できる本当の脆弱性ですか？

4

2 に答える 2

2
  • 攻撃者は偽の信頼できる証明書をブラウザにインストールし、セッションを乗っ取ります。
  • サイトへのリンクは送信されますが、SSLへのリダイレクトが傍受され、非SSLセッションが開始されます。

他にもありますが、話はこれです。SSLは複雑で、独創的な方法で攻撃されることがよくあります。接続が安全である場合、人間のコードの複雑さやCPU時間のコストと比較して、ハッシュはほとんど価値がありません。ただし、SSLセッションが侵害された場合でも、キーは保存されています。望ましくない人がアクセスするべきではないという事実にもかかわらず、データベース内のパスワードをハッシュするのと同じように、SSLにもかかわらずキーをハッシュするのが賢明です。

于 2011-05-17T13:53:53.943 に答える
2

チャネルは安全かもしれませんが、エンドポイントについては何もわかりません。問題のブラウザ（およびそのプラグイン/拡張機能/ ...）によっては、キーがディスクベースのキャッシュのどこかにある可能性があります。ユーザーのコンピューター、そしてそれは永遠の終わりまでそこに座っている可能性があります。

これはそれほど興味深い脆弱性ではありません...さまざまなマルウェアがすでにディスクをトロールし、価値のあるものを探していることに気付くまで、現在のレートでは、一部のユーザーが感染します（Webサイトのユーザーが20人しかない場合を除く）。 ））。

したがって、CPUサイクルを数回節約するために、非常に強力な暗号化メカニズムを捨てないでください。これは潜在的に危険なマイクロ最適化IMNSHOです。

于 2011-05-17T14:01:51.840 に答える