WCFでのHMAC認証の明確化

Question

私は、WCFでのRESTfulなWebサービスに関するいくつかの記事、より具体的にはこれらの方法についての認証方法について説明してきました。私が参照している主な記事は、Aaron SkonnardのRESTful Web Services with WCF 3.5です。 HMAC認証を特に扱う別のものは、Skonnardsの論文に基づくItai Goldstiens articleです。

両方の記事で参照されている「ユーザーキー」について混乱します。ユーザー名とパスワードの両方をユーザーに要求するクライアントアプリケーションがあります。これは、私は System.Security.Cryptography.HMACMD5クラスを初期化するために使用する鍵は、単にユーザー パスワードであることを

• を意味するのでしょうか？板井の記事 （下図）でのMacを作成するために使用される方法は、私は右のkeyは、ユーザー パスワードとtextであると考えているのですが与えられ

• は、私たちが使用している文字列が 詳細が実際に正しいことを確認しています？私の例で

  public static string EncodeText(byte[] key, string text, Encoding encoding) 
  { 
      HMACMD5 hmacMD5 = new HMACMD5(key); 
      byte[] textBytes = encoding.GetBytes(text); 
      byte[] encodedTextBytes = 
       hmacMD5.ComputeHash(textBytes); 
      string encodedText = 
       Convert.ToBase64String(encodedTextBytes); 
      return encodedText; 
  } 
  

、textパラメータは、（リクエストヘッダとして利用できるようにし、リプレイ攻撃を防ぐために使用される）、要求URIの組み合わせ、共有秘密およびタイムスタンプであろう。

この形式の認証はまともですか？私はanother threadここに来て、上記の記事で定義されているメソッドが "..a（sic）醜いハック"であることを示唆しています。著者は理由を示唆していませんが、私がこれについて読んでそれを働かせるのに数時間を費やしたことを考えると、それは落胆しています。しかし、この質問に対する受け入れられた答えは、カスタムHMAC認可スキームについて語っているので、HMACアルゴリズム自体の使用ではなく、醜いハック参照が単にHMAC認可スキームの実装である可能性があります。

以下の図は、the wikipedia article on Message Authentication Codeの場合です。私はこれが安全な方法でなければならないと感じていますが、私はそれが正しく使用されていることを理解していることを確認したいだけです。

Answer 1

キーユーザーのパスワードがあることが、あなたは絶対にこのを行うべきではないことができます。

• 最初に、キーは出力ハッシュのサイズに等しい最適な長さを持ち、ユーザーのパスワードはほとんど同じではありません。
• 第2に、適切なキーであるために、これらのバイトで十分なランダム性（専門用語を使用するためのエントロピー）が決して存在しません。
• 第3に、リプレイ攻撃を防止しているにもかかわらず、どのような種類の要求にも署名できる可能性があります。共有秘密を保持することもできます（ある時点でサーバーによってブロードキャストされるか、ブロードキャストの場合、中間者の攻撃では簡単にそれをつかんで保存することができますが、ユーザーがパスワードを変更しない限り、それを考えるべきだと思います。
• HMACMD5を使用して4番目の停止 - HMAC-SHA-256を最低限使用してください。あなたも理想的には、セッションベースおよびこれは一時的なものを含むべきである - しかし、一般的PBKDF2のようなものを使用して - このキーは非常に少なくともユーザのパスワードから生成される一連のバイトでなければなりません

攻撃者が知ることはできません。

しかし、多くの人が、私があまりにも妄想的すぎると言っているかもしれません。

私は個人的に私は認証の専門家ではないことを知っています - それは非常に繊細なバランスのとれた行為です - だから私はピアレビューと実績のある技術に頼っています。たとえば、SSL（クライアント証明書による認証）の弱点があるかもしれませんが、ほとんどの人がSSLを使用しています.SSLの弱点のために私のシステムの1つが悪用されると、それは自分の責任ではありません。しかし、脆弱性のために悪用された場合、私はそれを識別するのに十分な賢さを持っていませんでしたか？私は自分自身を玄関から蹴っていた。

私の休憩サービスのために、認証のためにSHA512と512ビットのランダムな塩を使用してストレッチ作業を行っています（多くの人がそれを言っていますが、しばらくそれを変更する必要はありません）。 ）、認証されたセッションを永続化するために、認証やその他のサーバー専用の既知の情報から派生したセキュアトークン（HMACで署名され、AESで暗号化されたもの）を使用します。トークンは、Asp.Netが認証クッキーを形成するのと同じ方法でステートレスです。

パスワード交換は本当にうまく機能し、SSLを使わなくても（パスワード保護で）安全で、クライアントとサーバーの両方を認証するという追加の利点があります。セッション永続性は、サイトとクライアントに基づいて調整できます。トークンには独自の有効期限と有効期限の値が含まれており、簡単に調整できます。クライアントID情報をそのトークンにも暗号化することで、クライアント提供の値から復号化された値を単純に比較することによって、別のマシンへの重複を防ぐことができます。 IPアドレス情報を知っているだけですが、偽装することはできますが、主にローミングネットワーク上の正当なユーザーを考慮する必要があります。