問題タブ [http-digest]

HTTPダイジェスト認証を使用するサーバーと通信するアプリがあります。

iPhone内の「セッション」管理は、私たちの開発者にとってはかなり「ブラックボックス」のように思えます。フレームワークがhttpセッションをどのように処理/永続化するかがわからないというのは本当ですか？

私がここで薄暗いだけの場合、誰かがiPhoneでHTTPダイジェスト認証を処理する方法を説明してくれるでしょうか？

私の基本的な実行は次のとおりです。

• 安全なURLにリクエストを送信します
• サーバーは401を送信します
• クライアントはクレデンシャルを作成して保持し、それをサーバーに返します
• サーバーは資格情報を検証し、検証された場合は要求を完了し、検証されなかった場合は別の401を送信します。
• URLを保護するために後続のリクエストを行います
• サーバーが再度認証を要求します.......。

これは単一のリクエストで機能しますが、追加の後続のリクエストを行うと、サーバーは再度承認をリクエストします。サーバーは特定のユーザーのセッションを永続化していますが、iPhoneは何らかの理由で同じセッション内で要求を行っていません...したがって、サーバーは認証オブジェクトを破棄し、クライアントごとに新しい認証オブジェクトを作成する必要があります保護されたURLにリクエストを送信します。

これは正しい動作ではないと確信しています。

この状況でブラウザがどのように動作するかを見ると、次のようになります。

• ブラウザが安全なURLからデータを要求する
• サーバーは401を送信します
• ブラウザはユーザーに資格情報の入力を求め、それを保持し、サーバーに渡します
• サーバーは資格情報を検証し、検証された場合はデータを返し、そうでない場合は別の401を送信します。
• ブラウザがセッションを管理しているため、URLを保護するために行われた後続の要求では、資格情報の入力は求められません。

NSURLCredentialを作成し、NSURLCrendtialStorage内に永続化しています。次に、アプリが「didReceiveAuthenticationChallenge」を受信すると、ストレージからクレデンシャルを取得して返し、クレデンシャルが存在しない場合は作成します（最初のリクエストで）。

どんな助けでも大歓迎です。ありがとう。

OK、これは奇妙な質問に聞こえるかもしれません。私に飛びつく前によく読んでください。;-)

次の状況を想像してください。

1. サーバーとクライアントがあります。
2. それらは SSL を使用して接続します。
3. クライアントはパスワードを使用してサーバー上にアカウントを作成します。
4. しかし、彼が実際にネットワーク経由でサーバーに渡すのは、パスワードのハッシュ (+salt) です (パスワードではありません)。
5. サーバーは、この受信したパスワードのハッシュをDBに保存します（ソルトで再度ハッシュされます）
6. ログオン時に、認証のために、ユーザーはパスワードのハッシュを再送信します (パスワードではありません!)。

わかりました、はい、これは奇妙に聞こえると思います。はい、会話全体が SSL で行われるため、パスワードのプレーンテキストを送信するだけでかまいません。はい、プレーンテキストのパスワードをハッシュ形式で安全に保存できることはわかっています。

私が推進しているポイントは次のとおりです。「あなたのパスワードを知ることはありません」と正直に言うことは、私たちのビジネスにとって有益です。

「パスワードをプレーンテキストで保存しない」と言っているわけではありませんが、実際には、決して、決してそれを知りません。あなたはそれを私たちに決して与えません。

(これが必要な理由は関係ありません。ユーザーのパスワードは、ファイルの暗号化などの他のものに使用されていると言えます)。

はい、これを行う通常の方法では、「ハッシュを行っている間、パスワードはメモリ内のプレーンテキストで5ミリ秒しか保持されない」と言うかもしれませんが、これは否定可能性に関するものです。つまり、100% パスワードを受け取っていないと言えます。

では、質問は次のとおりです。

• この種のことを以前に行ったり聞いたりしたことのある人はいますか?

• これを行うことの安全性への影響は何ですか？

マイナス面が見えず困っています。例えば：

• リプレイ攻撃なし (会話は SSL を使用して暗号化されているため、攻撃者はハッシュを見ることができません)
• ハッシュ自体がハッシュ化されているため、DB を参照できません。

OK、あなたは今私に飛び乗ってもいいです:)

感想、コメント大歓迎です。

ありがとう、

ジョン

更新: 明確にしたかっただけです: これが認証プロセスのセキュリティの何らかの形での改善であるとは提案していません。ただし、代わりに、サーバーからでも、ユーザーの「実際の」パスワードを秘密のままにすることができます。したがって、たとえばファイルの暗号化に実際のパスワードが使用されている場合、サーバーはそれにアクセスできません。

これが必要な理由には完全に満足しています。問題は、それが認証プロセスのセキュリティを妨げるかどうかです。

HTTPダイジェストをサポートするRubyライブラリはありますか？

私は 2 つの小さな http サーバーを持っています。1 つは太陽 (com.sun.net.httpserver) サーバーを使用し、もう 1 つは組み込みの桟橋を使用します。現在、少なくとも jetty サーバーで HTTP ダイジェストを動作させようとしています (これが、sun httpserver の代わりに jetty を使用する理由の 1 つです)。私が使用するサーバーに関係なく、基本的なセットアップはSpring IOCコンテナーを介して行われます。

私はこの目的でサーブレットを使用するのが好きではありません (まあ、jetty を使用して HTTPServletRequest および HTTPServletResponse オブジェクトを取得します)。Spring セキュリティは初めてです (HTTP に関して最も柔軟なアプローチであるように思われるため、Spring セキュリティを使用しているだけです)。ダイジェスト認証)。春のセキュリティについて私が見つけたのは、かなり簡潔に文書化されているか、完全にサーブレット/フィルター指向でした。

サーバーで http ダイジェストを有効にする最も簡単な方法を知りたいです。そして、春のセキュリティが答えである場合、春のクラスを IOC コンテナに接続する方法。httpダイジェストを処理するには、手動のアクションが必要になると想像できます。いくつかの開始のヒントがある限り、それは私にとっては問題ありません。

2つのHTTP認証があるようです：基本アクセス認証とダイジェストアクセス認証

したがって、一般的に、ユーザーがURLにアクセスしようとすると、Webサーバーが401 Unauthorizedを返し、ブラウザがアプリウィンドウをポップアップしてユーザー名とパスワードを要求し、HTTPヘッダーにクレデンシャルを設定してから再度HTTPリクエスト。

http：// peter：mypassword@www.somesite.comはどうですか？401が戻ってくるのを待たずに、事前にユーザー名とパスワードを提供することになっていますか？どういうわけか、 http：// peter：mypassword@www.google.comまたはyahooを試しましたが、Fiddlerの内部（ネットトラフィックを監視するため）で、HTTPリクエストにクレデンシャル情報が表示されませんか？

GWT 2.2 と restlet-gwt-2.1m4 を使用しています。

HTTP Digest を使用する REST サービスを呼び出そうとしています。

そこで、Restlet wiki のチュートリアルを使用しました。

http://wiki.restlet.org/docs_2.1/13-restlet/27-restlet/46-restlet/112-restlet.html

まず、これはコンパイルされません:

だから私はそれを

2 つ目の問題は、リクエストが送信されないことです。Firebug で確認しましたが、何もありません (GET 要求はありません)。

resource.get(); のようです。何も送信していません。

私が欠けているものは何ですか？チュートリアルのコードは実際に動作しますか?

前もって感謝します

iPhoneアプリに接続するアプリがあり、それがhttp_digestを介してユーザーを認証します。

私は authlogic を使用しています。私のスキーマでは、Web サイトのユーザーは「ユーザー」であり、電話アプリのユーザーは「人」です。だから、私は user_sessions と people_sessions を持っています。http_digest 認証を処理するために、次のような authenticate_or_request_with_http_digest メソッドを使用しています。

パスワードが nil であることをログで確認できます。メールのみが authenticate_or_request_with_http_digest ブロックの内部に渡されます。

次のようなcurl呼び出しでこれをテストしています：

「fakename@madeup.xyz」と「apass」がブロックの内部に渡されることを期待しています。パスワードを取得したら、電子メールとパスワードの組み合わせを使用して、通常の方法でユーザーを検索 (または検索しない) できます。パスワードにアクセスする方法を知っている人はいますか?

アドバイスに感謝します - マックス

編集 - さらにグーグルで調べてみると、この方法を間違って使用していると思います。パスワードまたは暗号化されたパスワードを返すだけです。しかし、それを http_digest ユーザー名の一部として渡されたパスワードと比較するにはどうすればよいでしょうか?

Restlet 2.0.8を使用しており、アプリケーションインスタンスがorg.restlet.Application＃createInboundRoot（）を上書きしています。そこで、Routerインスタンスを作成し、以下のコードのように、（現時点では）DigestAuthenticatorを返します。

私が達成したいのは：

• ダイジェスト認証を使用するEchoResourceがあり、StatusResourceはHTTP基本認証を使用する必要があります

これはRestletsで可能ですか？

最高、クリス

できるだけ純粋な REST アプローチを維持しようとして、最後の部分までアプリケーションがAPI になると判断しました。

残念ながら、私は 1 つのつまずきに達しました。PHP でダイジェスト認証ハンドラーを作成した後、フォームベースの認証方法ほど Web ブラウザーのユーザーにとって使いやすいエクスペリエンスを作成できないことに気付きました。

この理由は、HTML フォームからユーザー名とパスワードを使用して Javascript を介してダイジェスト認証応答をシミュレートできたとしても (nonce生成方法により、スクリプトに安全に値を与えることができます)、失敗すると、ブラウザには、標準の醜い認証プロンプトが引き続き表示されます。

これを回避する方法はありますか？以前の質問は を参照していますmozBackgroundRequestが、それはクロスブラウザーとは思えません。

ありがとう！

ファイアウォール用に http_basic を http_digest に変更したいのですが、http_digest の設定方法が実際には文書化されていません。

参照が不完全または最新ではないようです:

http://symfony.com/doc/2.0/reference/configuration/security.html

ただし、本の例ではレルムを使用し、プロバイダーは使用していません。

http://symfony.com/doc/current/book/security.html

少なくともその例は機能しますが、http_basic を http_digest に変更すると (文書化されていない) キーがありません。

ErrorException: Notice: Undefined index: key in ..\vendor\symfony\src\Symfony\Bundle\SecurityBundle\DependencyInjection\Security\Factory\HttpDigestFactory.php 行 80

キーの追加は機能しているように見えますが、ログイン後に別のエラーが発生します:

致命的なエラー: 79 行目の ..\vendor\symfony\src\Symfony\Component\Security\Http\Firewall\DigestAuthenticationListener.php の未定義メソッド Symfony\Component\Security\Http\EntryPoint\DigestAuthenticationEntryPoint::getKey() の呼び出し

それが、構成に何が欠けているのか見当がつかない点です。Symfony 2 を使用した http_digest の実際の例が必要です。