web-dev-qa-db-ja.com

RESTの適切なメッセージ認証コード

私のRESTサービスは現在、SCRAM認証を使用して、呼び出し元とユーザーにトークンを発行しています。

SCRAM交換によって発行されたトークンには有効期限があり、その後はサインインを繰り返す必要があります。また、JSONPエンドポイントの準備として、個人用（私たちのサービスを個人用に使用する）の統合を簡素化する有効期限のない「無限」トークンを発行します。

呼び出し元の権限（トークンが関連付けられているアカウント）を取り消し、IPを禁止する機能、および任意のタイプのリクエストに任意の期間にクォータを課す機能があります。

ただし、実装していないのは、リクエスト用のMACです。私はそれについてもっと考えましたが、一部のリクエストではこれが必要だと思います。トークンが盗まれる可能性があり、これを特定して関連する呼び出し元アカウントを非アクティブ化する前に、ユーザーアカウントにいくつかの損害が発生する可能性があるためです。

多くのシステムでは、MACはリクエストの本文またはクエリ文字列から生成されますが、ASP.Net Web APIを使用していて、本文を2度読みたくないため、これを実装するのは困難です。同様に重要なこととして、発信者がサービスにアクセスできるように簡単にしたいと考えています。デスクトップ/モバイルアプリとWebブラウザーの両方をサポートできる必要があります。

したがって、私が考えているのは、登録時にMACキーをユーザーに送信し、ユーザーにリクエストMACを計算させることです。

  • uRL、おそらくマイナスのクエリ文字列
  • 動詞
  • リクエストip（一部のモバイルデバイスでは潜在的にバリアであり、definitelyはJavaScriptにあります）
  • クライアントがリクエストを発行するutcの日付と時刻。

最後の1つについては、もちろん、クライアントにその文字列をリクエストヘッダーで送信させます-そして、それを使用して、リクエストが十分に「新鮮」かどうかを判断できます。

私の考えでは、これはメッセージ本文の改ざんを防止するものではありませんが、悪意のあるサードパーティによるさまざまな要求のテンプレートとして使用するためのモデル要求の使用を防止します。私は、ミドルアタックの中で最も攻撃的な人だけがこれを覆すことができると信じています、そして私たちのサービスがそれを保証するのに十分価値のある情報や能力を提供するとは思いません。

これらのサービスでは、機密事項についてもSSLを使用します。そして、これを行うと、PRNGを使用して生成されたキーでHMAC-SHA-256を使用します。

これで十分ですか？何か逃したことがありますか？

私はセキュリティに関しては初心者ではないと思いますが、それに取り組むときはいつも私は疑わしいです。ですから、このコミュニティーに連絡してもらい感謝します！

resthttpauthentication
7
Andras Zoltan

トランスポートにSSLを使用し、それを適切に行う場合、追加のMACは冗長になります。そして、それに関しては [〜＃〜] scram [〜＃〜] もそうです。 SCRAMの セールスポイント は、SSLが使用されている状況が不適切である、つまり適切なサーバー認証がない場合に抵抗することが想定されていることです（残念ながら、 それが起こる ）。しかし、このような状況ではSCRAMのセキュリティ論は弱いものです。なぜなら、それは 中間者攻撃 ;を防止しないためです。そして、MitMがなければ、SSL内の基本的なプレーンパスワードは既に十分です。プレーンなパスワードに対するSCRAMの唯一の利点は、MitMの場合、攻撃者がパスワードをすぐには知らないことです。彼は依然としてすべての交換されたデータを確認し、独自のコマンドを挿入できます。そして、 オフライン辞書攻撃 を実行するのに十分なデータを取得します。

MACを追加するための提案では、MACkeyがどこから来たかは述べていません。これは重要です。 MACは、キーが攻撃者に知られていない限り、値を持ちます。しかし、クライアントとサーバーが攻撃者に知られていないキーをすでに共有している場合、なぜ彼らはパスワードとSCRAMでさえ邪魔するのでしょうか？ 事前共有キーTLS 、つまり相互認証と暗号化の基礎として共有キーを使用したSSL/TLSを使用できるようにする：証明書がまったくない（証明書の検証が正しくないため）、滑らかで高速な操作。

さらに良いことに、クライアントとサーバーがパスワードを共有し、証明書を使用したくない場合、オフライン辞書攻撃を恐れた場合、サーバーにパスワードをそのまま保存したくない場合、解決策は TLS-SRPです。 。クライアントとサーバーは共通のパスワードを基準にして相互に認証し、サーバーはパスワードを保存せず、それに相当するハッシュのみを保存します。パスワードは、オフライン辞書攻撃から安全です MitM試行（試行が阻止されるだけでなく、攻撃者は「自宅でパスワードを試す」ために十分なデータを取得しません）。

SCRAM設計者は仕様のセクション9で次の段落を追加したため、おそらくSRPについていつか知らされていました。

この攻撃から保護する認証メカニズムが利用できます（例：EKEクラスのメカニズム）。 RFC 2945 [RFC2945]は、そのようなテクノロジーの例です。 WGは、SCRAMの基礎としてEKEのようなメカニズムを使用しないことを選択しました。

[〜＃〜] pake [〜＃〜] プロトコル（最初に既知のPAKEプロトコルの名前である "EKE"を不適切に呼び出す）プロトコルを拒否する理由はまったくわかりません。

4
Thomas Pornin

ほとんどの設定では、HTTPS（SSL）とCSRFトークンを使用することをお勧めします。これは、Webアプリケーション/ Webサービスを保護するための標準アーキテクチャです。 HTTPS + CSRFトークンを使用する場合、MACは必要ありません。

「機密情報のみにSSLを使用する」という考えを押し戻します。それにはいくつかの問題があります。サイト全体でHTTPSを使用することをお勧めします。 SSLをサイト全体で使用する場合の長所と短所、およびSSLの実装方法については、このサイトを検索してください。

あなたのインターフェイスがプログラムで使用するためだけのものなのか、それとも人間が使用するものなのかはわかりません。その場合、クライアント側に人間がWebブラウザーの後ろに座っている場合、HTTPSはおそらくユーザーにとって最高の使いやすさも提供します。

0
D.W.