チャレンジ レスポンス 認証。 チャレンジレスポンス認証って何?

平成26年春期問38 チャレンジレスポンス方式|応用情報技術者試験.com

チャレンジ レスポンス 認証

HTTP はアクセス制御と認証の基本的な枠組みを提供しています。 最も一般的な HTTP 認証は、"Basic" 認証に基づいています。 このページでは、HTTP の認証の枠組みを紹介し、サーバーで HTTP の "Basic" 認証を使用してアクセスを制限する方法を紹介します。 一般的な HTTP 認証の枠組み は、サーバーがクライアント要求を し、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義します。 チャレンジとレスポンスの流れは以下のようになります:サーバーは少なくとも1回目の challenge でクライアントに Unauthorized レスポンスステータスを返し、 レスポンスヘッダーを含めて認証方法を提供します。 サーバーで自身を認証したいクライアントは リクエストヘッダフィールドにクレデンシャルを含めることでそれを行うことができます。 通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい Authorization ヘッダーを含むリクエストを発行します。 図に示すような "Basic" 認証の場合、やり取りを安全に行うために HTTPS TLS 接続を介して 行われなければなりません。 プロキシ認証 プロキシ認証にも同じチャレンジとレスポンスのメカニズムを使用できます。 この場合、認証を必要とする中間プロキシです。 リソース認証とプロキシ認証の両方が共存できるため、異なるヘッダーとステータスコードのセットが必要です。 プロキシの場合、チャレンジしているステータスコードは Proxy Authentication Required で、 レスポンスヘッダは プロキシサーバーに資格情報を提供するために、 リクエストヘッダーが使用されます。 アクセスの不許可 特定のリソースにアクセスするのに十分ではないが有効な資格情報を プロキシ サーバーが受け取った場合、サーバーは Forbidden ステータスコードでレスポンスする必要があります。 Unauthorized または Proxy Authentication Required とは異なり、このユーザーは認証できません。 オリジン間の画像の認証 ブラウザーによって最近修正された潜在的なセキュリティホールは、クロスサイトイメージの認証です。 以降、異なるオリジンから現在のドキュメントにロードされた画像リソースは、HTTP認証ダイアログ をトリガすることができなくなり、攻撃者が任意の画像をサードパーティ製のページに埋め込んでユーザーの認証情報を盗むことを防ぎます。 HTTP 認証の文字エンコーディング ブラウザーはユーザー名とパスワードに utf-8 エンコーディングを使用します。 Firefox は ISO-8859-1 を使用していましたが、他のブラウザーとの互換性のために utf-8 に変更され、 で説明されているような潜在的な問題を回避します。 WWW-Authenticate 及び Proxy-Authenticate ヘッダー と レスポンスヘッダーは、リソースへのアクセスに使用する認証メソッドを定義します。 どの認証方式を使用するかを指定する必要があるため、認証を希望するクライアントは資格情報の提供方法を知ることができます。 これらのヘッダーの構文は次のとおりです。 realm は保護された領域を記述するため、または保護の範囲を示すために使用されます。 これは、「ステージングサイトへのアクセス」などのようなメッセージで、ユーザーがアクセスしようとしているスペースを知ることができます。 Authorization and Proxy-Authorization headers と リクエストヘッダーには、 プロキシ サーバーを持つ User agent を認証するための認証情報が含まれています。 ここでは、タイプが再び必要となり、その後にどの認証方式が使用されるかに応じて符号化または暗号化されることができるクレデンシャルが続きます。 Authorization: Proxy-Authorization: 認証方式 一般的な HTTP 認証フレームワークは、いくつかの認証方式によって使用されます。 スキームはセキュリティ強度とクライアント、またはサーバーソフトウェアでの可用性が異なる場合があります。 最も一般的な認証方式は "Basic" 認証方式であり、これについては以下で詳しく説明します。 IANA はを管理していますが、Amazon AWS などのホストサービスが提供する他のスキームもあります。 一般的な認証方式には次のものがあります。 Basic 、base64 でコード化された認証情報を参照 ,• Bearer 、OAuth 2. 0 で保護されたリソースにアクセスするベアラトークンを参照 ,• Digest を参照、Firefox では md5 ハッシュだけがサポートされています。 SHA 暗号化のサポートについては を参照 ,• HOBA 3章 を参照、HTTP オリジン認証 HTTP Origin- Bound Authentication 、デジタル署名ベース ,• Mutual を参照 ,• AWS4-HMAC-SHA256 を参照. Basic 認証方式 "Basic" HTTP 認証方式は で定義されており、Base64 を使用してエンコードされたユーザー ID とパスワードのペアとしてクレデンシャルを送信します。 Basic 認証の安全性 ユーザーID とパスワードはネットワークを介してクリアテキスト base64 でエンコードされていますが、base64 は可逆エンコードです として渡されるため、Basic 認証方式は安全ではありません。 これらの追加のセキュリティ強化機能がなければ、機密情報や重要な情報を保護するために Basic 認証を使用しないでください。 Apache 及び Basic 認証によるアクセス制限 Apache サーバー上のディレクトリーをパスワードで保護するには、. htaccess ファイルと. htpasswd ファイルが必要です。 htaccess ファイルは通常、次のようになります。 htpasswd Require valid-user. htaccess ファイルは. htpasswd ファイルを参照し、各行にはユーザー名とパスワードをコロン ":" で区切って記述します。 実際のパスワードは この場合は md5 ので表示できません。 必要に応じて. htpasswd ファイルの名前を変更することができますが、このファイルには誰にもアクセスできないように注意してください。 Apache は通常. htpasswd ファイルを指します。 example. Chrome ではセキュリティ上の理由から、URL の username:password 部分も。 Firefox ではサイトが実際に認証を要求するかどうかをチェックし、そうでない場合 Firefox はユーザーに「"username" というユーザー名で "www. example. com" というサイトにログインしようとしていますが、ウェブサイトは認証を必要としません。 これはあなたを騙そうとしている可能性があります。 」と警告します。 関連情報• , ,• Guides:• Resources and URIs• HTTP guide• HTTP security• References:• HTTP headers• HTTP request methods• HTTP response status codes• CSP directives• CORS errors• Feature-Policy directives•

次の

チャレンジ・レスポンス認証方式

チャレンジ レスポンス 認証

チャレンジ・レスポンス認証方式 スポンサードリンク チャレンジ・レスポンス認証とは、認証サーバーが「チャレンジ」という毎回変化するランダムなデータをクライアントに送信します。 これを受け取ったクライアントは,チャレンジとユーザーのパスワードを基に演算して「レスポンス」というデータを算出します。 そしてこのレスポンスをサーバーに送ります。 サーバーでは,自身に登録されているパスワードとチャレンジを使って,クライアントと同じ演算でレスポンスを算出し,クライアントから送られてきたレスポンスと照合します。 そして,両者が一致すれば,クライアントのパスワードが正しいと判断し,クライアントを認証します。 サーバーが送るチャレンジだけでレスポンスを作成したり,チャレンジとレスポンスからパスワードを逆算するようなことはできません。 また,サーバーが送るチャレンジは毎回変わり,それを基に算出したレスポンスも毎回変化します。 このため,クラッカがパケットを盗聴してもパスワードは解読できません。 また,レスポンスをコピーしてサーバーへログインしようとしても,ログインするたびにレスポンスが変わるため,認証に失敗します。 チャレンジ・レスポンス認証は、などの脅威にたいして有効です。

次の

チャレンジ・レスポンス認証方式

チャレンジ レスポンス 認証

これを実装するための仕組みを意味する場合もある。 固定式のパスワードだと,セキュリティ向上のために定期的に変更したり,類推されにくい文字列を使用したりする必要がありました。 逆に考えれば,「パスワードを毎回異なるものにして,意味のない文字列を使う」ことができれば理想的です。 これを仕組みとして実装したものが,ワンタイム・パスワードです。 ワンタイム・パスワードの実装は製品によってまちまちです。 しかも,見たり使ったりしても内部の仕組みはわかりません。 そこで,今回はワンタイム・パスワードを実現するために利用されている代表的な技術を2つ紹介します。 どちらも「毎回異なるパスワードを利用する」と仕組みを実現するために,事前に認証する側とされる側でハードウエアや関数などを共有しておきます。 違いはどんなハードウエアや関数を共有するかという点です。 時刻同期方式(タイムスタンプ方式)のしくみ その一つがタイムスタンプ方式です。 タイムスタンプ方式では,利用者(認証される)側にトークンと呼ばれるパスワード生成器をあらかじめ配布しておきます。 トークンにはICカードのようなものUSBキーのようなもの,キーホルダーのような形をしているもの,インストールして使用するソフトウエア・タイプなど,さまざまな形態があります。 そして,このトークンには,例えば6桁の数字が表示されていて,これが時刻の経過に伴って別の数字に切り替わります。 この数字がパスワードというわけです。 ユーザーが認証を受けるときは,自分のID(識別番号)とともに,トークンに表示された数字をパスワードとしてサーバー側(認証する側)へ送信します。 サーバー側では,誰がどのトークンを使っているか,そして各トークンがどの時刻にはどんな数値を表示するかを把握しています。 そこで,サーバーはアクセスしてきた時刻と送られてきたパスワード,および識別番号を検証することにより,アクセス元が正規ユーザーかどうかを認証することができます( 図1)。 図1 タイムスタンプ方式のしくみ なお,トークンが表示する数字を切り替えるタイミングは,より短時間になっていた方が安全は高まります。 ただ,あまり細かすぎると,使い勝手が悪くなってしまいます。 現在流通している製品では,1分間に1度だけ数字を変化させるのが主流のようです。 タイムスタンプ方式では時刻同期が必須 このタイムスタンプ方式では,実装に当たって考えておかなければならないことがあります。 それはトークンとサーバーの時刻同期です。 いくら機器の性能が良くてもトークンとサーバーはまったく別の機器です。 このため,時刻のズレが生じます。 このズレを吸収するための仕組みが必要になるのです。 ここでは時刻同期のための仕組みの一例を紹介しましょう。 まず,すべての基準となる時刻を明確にしておく必要があります。 今回は認証する機器となる,サーバーの時刻を基準にイメージしてください。 サーバーの現在時刻に対して,トークンの現在時刻がまったく同じならば問題はありませんが,ズレは必ず生じているものです。 そこで,例えば「サーバーの現在時刻に対してプラス・マイナス1分」などとズレに対しての許容範囲を決めます。 仮にユーザーAのトークンがサーバーの時計に対して1分進んでいた(図1の状態で9:01)としましょう。 このタイミングでユーザーAが認証を試みる際には「440613」という値を送信してきます。 ここで「885139」という値が送られてくれば問題なく認証できますが,異なる値が送られてきたので許容範囲となっている前後1分のパスワードと一致するかを調べます。 調査の結果9:01のパスワードと一致するので,ユーザーAのトークンは1分進んでいるのだろうと推測し,許容範囲内と判断して認証します。 そして,サーバーはトークンとの時間のズレ(ユーザーAのトークンは1分進んでいる)を記憶しておき,次にアクセスを受けたときは自分の時刻よりも1分進んだ時刻を起点にプラス・マイナス1分を新たな許容範囲とします。 でも,これだと久しぶりにアクセスしたときなど,時刻のズレが許容範囲を超えてしまうかもしれません。 ただし,大きなズレが発生するには,通常は長い時間がかかるので,この部分は運用でカバーするのが一般的です。 例えば,「最低でも1カ月に一度は必ずアクセスすること」といった規則を決めておき,誤差が許容範囲を超えてしまう前に修正するようにするのです。 また,著しくズレが大きくなってしまった場合に管理者が同期の取り直しを行い,強制的に補正できるようにする製品もあります。 チャレンジ・レスポンス方式 チャレンジ・レスポンス方式で使用されるチャレンジとは,「意味のないビット列」のことです。 この値は同じものを使用せず,毎回ランダムに変化させます。 レスポンスとは「チャレンジを計算した結果算出された答」のことです。 この方式を利用するためには,あらかじめサーバーとクライアントでレスポンスを生成するための仕組みを共有することが必要になります。 例えば,あらかじめ電卓のような機器(レスポンス生成器)を持っておき,送られてきたチャレンジを入力してボタンを押すとレスポンスが表示され,これを認証画面に入力する,などのような流れを想像していただければイメージしやすいでしょう。 ここでは認証する側とされる側であらかじめ「関数」を共有していると考えて,具体的な流れを確認していきましょう( 図2)。 図2 チャレンジ・レスポンス方式の仕組み ユーザーがサーバーへアクセス要求を送ると(1),サーバーからユーザーに意味のないビット列が送られてきます(2)。 この意味のないビット列が「チャレンジ」です。 ユーザー側ではこのビット列を基に,サーバー側と事前に共有している関数を使って別のビット列を算出します(3)。 この算出されたビット列が「レスポンス」です。 そして,このレスポンスをサーバーへ返信します(4)。 サーバー側では,ユーザーに送ったチャレンジと自分が記憶している関数を使って(3)'独自にレスポンス(4)'を計算します。 そこで,サーバーはユーザー側から送られてきたレスポンスと独自計算したレスポンスを比較します(5)。 そして,これら二つのレスポンスが一致したら,事前に共有していた関数が同一であると判断できます。 つまり,サーバーはアクセス元が正規ユーザーであると判断でき,認証します(6)。 サーバー側が最初に送るチャレンジを毎回変えることで,レスポンスも毎回変化します。 このことから,ワンタイム・パスワードの要件(使い捨て)を満たしていることがわかります。

次の