11

このトピックで他の質問を検索しましたが、これに対する答えが見つかりませんでした。私が間違っているかどうか教えてください。私はこのトピックの初心者であり、喜んで私を修正することができます. これが私が実際の瞬間に考えていることです：

私は今から 2 日間 Web をサーフィンして、Web リクエストを承認するための実際の最新技術を調べました。私がすぐに理解したのは、OAuth 2.0 が最も一般的な標準のようだということです。しかし、OAuth 2.0 自体は、標準化されている以外はすべてです。私の視界からは、大企業ごとにさまざまなカスタマイズがごちゃごちゃになっています。とにかく、承認情報を交換するには、Mac-Tokens と Bearer-Tokens の 2 つの手法があります。

私の意見では、Mac-Tokens はより多くのセキュリティを提供します。では、なぜ広く導入されていないのでしょうか。私が見つけた唯一の理由は、もう少し複雑だからです。また、クライアントが 100% 信頼されていない場合、クライアントはシークレットを保存する必要があるため、Mac-Tokens は推奨されないという話を何度か聞きました。しかし、違いはどこにありますか？いずれにせよ、クライアントは Authorazation-Information を保存する必要があります。私の意見では、それがベアラートークンであろうとマックシークレットであろうと関係ありません。しかし、違いを生むのは、( bearer-token ではなく) mac-secretがすべてのリクエストでネットワーク経由で送信されないことです。

では、mac-tokens を使用しない正当な理由を教えていただけますか? （もう少し努力することは別として）何か足りないのですか？または、2 つのトークン手法を誤解していますか。

読んでくれてありがとう。

4

4 に答える 4

3

危険なのは、クライアントが SSL/TLS 証明書が有効であることを主張せずに続行する場合 (これは多くのクライアントが失敗するステップです)、ベアラー トークンが中間者攻撃の影響を受けやすくなるということです。

Mac トークンは、この攻撃の影響を受けません。Mac トークンは、SSL/TLS がない場合、または正しく使用されていない場合に、ある程度の信頼性を提供すると言うのが正しいかもしれません。

Mac トークンは、Bearer トークンの既知の弱点を強化します。

クライアントは、共有されている MAC キーで信頼されるべきではありません。クライアントごとに新しいキーを生成する必要があります。各クライアントを独自のキーで信頼することは、ベアラー トークンでクライアントを信頼することと同様に、セキュリティ リスクではありません。

オーソライゼーション グラントをアクセス トークンと交換するときに問題が発生すると思います。Mac 鍵の場合、これは対称秘密鍵を返します。クライアントが SSL/TLS 証明書のチェックを怠ると、これも MITM 攻撃の影響を受けやすくなります。

要するに、Mac トークンはより複雑であるためあまり好まれませんが、セキュアにするために SSL/TLS を適切に行う必要があります。そうすれば、ベアラー トークンもセキュアになります。

于 2016-06-01T14:27:21.500 に答える
3

私の意見では、答えは簡単かもしれません。ベアラー トークン メカニズムは SSL/TLS レイヤーの存在を前提としていますが、MAC トークンはそれを置き換えようとします。SSL/TLS は広く受け入れられ、使用されているのに、必要以上に複雑なことをするのはなぜでしょうか?

はい、最近ハートブリードの脆弱性で見られたように、多くのことは実際には期待したほど信頼できませんが、MAC の実装にも問題がないことを誰が保証しますか?

もう 1 つのポイントは、おっしゃったように対称秘密の交換です。絶対に信頼できるセカンダリ チャネルがない場合は、注意が必要です。また、クライアントを信頼することも問題になる場合があります。

于 2015-12-23T11:37:02.083 に答える
1

SSL/TLS が適切に使用され、クライアント資格情報が機密かつセルフサービスの方法で発行された場合、ベアラー トークンの代わりに MAC を採用するメリットはあまりありません。複雑さを増すだけです。client_secret の機密性を維持するのはクライアントの責任です。もちろん、セキュリティを向上させる MAC の考え方を好むクライアントもいます。

于 2017-02-08T15:02:58.420 に答える