2

だから私はHMAC認証に非常に慣れていないので、自分が何をしているのか、atmを読んでいるのか本当にわかりません。

私は次の記事/リンク/議論を適切に理解しようとしています:

RESTful WCF API で HMAC 認証を実装する方法

http://blogs.microsoft.co.il/blogs/itai/archive/2009/02/22/how-to-implement-hmac-authentication-on-a-restful-wcf-service.aspx

http://buchananweb.co.uk/security01.aspx

そうは言っても、いくつか質問があります。

  1. たとえば、.net で作成された loginAuthentication サービスがあり、iPhone アプリからアクセスする場合、最初のリンクを理解する後で他のトランザクション (削除、挿入サービスなど) に使用する文字列は?

    [ServiceContract]
    
    public partial class LoginService
    {
    
     [OperationContract]
     bool Authenticate(string username) {
       // stuffs
     }
    

    }

  2. そうは言っても、ユーザーを確認した後、ここで迷子になります。データベースに「タイムスタンプ付き」で何かを保存した方がよいでしょうか (誰かがこれについて教えてくれました。これについての議論も読みました)。それとも、リクエストが行われるたびにタイムスタンプがすでに添付されるように、暗号化されたメッセージ(最初の質問に応じて)でそれを返すだけですか?

    a. そして、そのタイムスタンプで何をしますか?

    b. 別のトランザクションでメッセージが再度送信されたときに使用されますか?

  3. 鍵と秘密のメッセージ。私が理解した方法は、キーがユーザーのパスワードになるということです。ユーザーが自分のユーザー名を送信した場合、そのユーザーのパスワードを使用してメッセージを開くことができますか? これは、ユーザーがすでにセッションを持っていて、データの取得を要求している場合、または削除、挿入などを要求している場合に意味があります。ユーザーのユーザー名とパスワードを認証するだけの場合でも、同じようにする必要がありますか?

お時間をいただきありがとうございます!

4

2 に答える 2

4

最初に言及したいのは、WCF Web Api はベータ プロジェクトであり、現在は開発されていないということです。RESTful サービスを開発するための優れたフレームワークである ASP.NET Web API に置き換えられました。

RESTful サービスと認証がどのように機能するかをよく理解したい場合は、Netflix API から始めるのが最適です。彼らはセキュリティ部分に関する多くのドキュメントを持っており、これは私が HMAC をより理解するのに役立ちました.

HMAC は、秘密鍵を使用してハッシュを作成します。クライアントとサーバーは両方とも、一致するハッシュを生成できるように秘密鍵のコピーを保持します。これにより、認証 (送信者が誰であるかを知る) とメッセージの整合性 (送信したメッセージが元のメッセージであり、改ざんされていないことを知る) の両方として機能するリクエストに「署名」できます。

署名は組み合わせて作成されます

1. Timestamp (unix epoc is the easiest to send in urls)
2. Nonce (a random number that can never be used twice to protect against someone re-using it)
3. Message (for a GET request this would be the URL, a POST would be the whole body)
4. Signature (the three previous items combined and hashed using the secret key)

上記のそれぞれをリクエストのクエリ文字列で送信すると、サーバーは最初の 3 つと秘密鍵のコピーを使用して署名を再作成できます。署名が一致する場合は、すべて問題ありません。

プレーンな HTTP を介した (ssl を介した HTTPS を使用しない) RESTful API では、送信されるすべての要求に署名します。これも認証され、メッセージの整合性が提供されるためです。それ以外の場合は、認証トークンを送信するだけで、ユーザーが認証されていることがわかりますが、比較するメッセージ ダイジェスト (HMAC ハッシュ) がない場合、メッセージが改ざんされていないことをどのように知ることができますか?

署名のサーバー側チェックを実装する簡単な方法は、System.Web.Http.AuthorizeAttribute の OnAuthorization をオーバーライドすることです (Mvc autorize 属性を使用しないようにしてください)。秘密鍵を使用してクライアント側で行ったのと同じように署名を再構築し、一致しない場合は 401 を返すことができます。その後、認証を必要とするすべてのコントローラーを新しい authorize 属性で装飾できます。

うまくいけば、これがあなたの混乱の一部を解消し、水をさらに濁らせないのに役立ちます. 必要に応じて、後でより具体的な例をいくつか提供できます。

参考文献:

Netflix Api ドキュメント: http://developer.netflix.com/docs/Security#0_18325 (署名の作成に関する部分に移動します。HMAC 署名を作成するための完全な .NET の例を示すリンクもあります)

HMAC 署名を作成するための .NET クラス http://oauth.googlecode.com/svn/code/csharp/OAuthBase.cs

私が書いたNetflix APIラッパー: https://bitbucket.org/despertar1318/netflix-api/overview

ASP.NET Web API : http://www.asp.net/web-api

于 2012-11-29T18:51:01.690 に答える
0

質問を順番に見る

...これに暗号化されていないユーザー名 (メッセージ) を渡し、true / false のみを返す必要がありますか、または後で他のトランザクション (削除、挿入サービスなど) に使用する暗号化された文字列を返す必要がありますか?

ブール値を返しただけでは、認証リクエストを後続のリクエストと照合する方法がありません。ある種の認証インジケーターを返す必要があります。従来の Web サイトでは、これはセッション cookie になります。インスタンスでは、共有キーとして機能する値を渡したいと考えています。

データベースに「タイムスタンプ付き」で何かを保存した方がよいでしょうか? または、リクエストが行われるたびにタイムスタンプがすでに添付されるように、暗号化されたメッセージでそれを返すだけですか?

セッションの類推に戻ると、質問 1 のキーを、セッションの有効期間/キーの有効性を示すタイムスタンプと共にどこか (データベース?) に保存する必要があります。それが永遠に続く場合は、タイムスタンプを気にしません。それ以外の場合は、有効期限が切れたときに何か言う必要があります。

私が理解した方法は、キーがユーザーのパスワードになるということです。ユーザーが自分のユーザー名を送信した場合、そのユーザーのパスワードを使用してメッセージを開くことができますか? これは、ユーザーがすでにセッションを持っていて、データの取得を要求している場合、または削除、挿入などを要求している場合に意味があります。ユーザーのユーザー名とパスワードを認証するだけの場合でも、同じようにする必要がありますか?

ここで HMACing が行われます。あなたには共有の秘密があり、メッセージがあります。これは、私が通常これらをすべて組み合わせる方法です。

すべてのメッセージをハッシュするデータの本体として使用します (そうすれば、誰かがハッシュとメッセージの一部をコピーしただけではないことを確認できます)。ステップ 1 で共有したキーを使用して、メッセージの本文をハッシュします。必要に応じてこれをソルトできます。ユーザー名を使用します。

最後に、メッセージにタイムスタンプ (できれば UTC) が含まれていることを確認してください。これにより、後でメッセージを再生するのを防ぐことができます。メッセージに応答しているサービスは、タイムスタンプを、想定している時間と比較できます。指定された範囲外にある場合、メッセージは失敗します。タイムスタンプは HMAC の一部になるため、誰かが日付を更新してメッセージを再生することはできず、メッセージが改ざんされるとすぐにハッシュが一致しなくなります。

于 2012-11-29T20:19:29.057 に答える