チャレンジレスポンス認証で使われるハッシュ関数の交換タイミングについて教えてください。

Question

チャレンジレスポンス認証でログインする際に、毎回サーバが異なるチャレンジを作成しクライアント側に送ることで
パスワードとチャレンジの組み合わせ+ハッシュ関数によるワンタイムパスワードが作成されるということはわかりました。

ただ、認証するにはお互いに使うハッシュ関数が同一でなければならないと思うのですが
どのタイミングの通信で交換(ネゴシエーション)しているのでしょか。

ご存じの方いらっしゃいましたら教えてください。
よろしくお願いします。

Comments

[ockeghem]

利用用途などを追記ください。HTTP認証としての話でしょうか?それとも独自のアプリケーションでの利用でしょうか?

[shum]

レスポンスありがとうございます。
申し訳ございません。
HTTP認証としての話です。

Answer 1

以下の記事を読んで勉強していただくのがよいと思います。

Digest認証 - Wikipedia

Digest認証の挙動 - Qiita

Digest認証はどのような脆弱性対策をしているか - Soon Lazy

ただ、認証するにはお互いに使うハッシュ関数が同一でなければならないと思うのですが
どのタイミングの通信で交換(ネゴシエーション)しているのでしょか。

ハッシュ関数は確かに同一でなければなりませんが、これは認証情報が載っていない最初のリクエストに対して 401 ステータスを返す際に、以下のように示します。

HTTP/1.1 401 Unauthorized
Server: nginx
Content-Type: text/html; charset=iso-8859-1
WWW-Authenticate: Digest realm="DiGest auth", nonce="I/h1oAGRBQA=36eb3af42b73413998417583a8c52bf38a9bb803", algorithm=MD5, qop="auth"

右スクロールしないと読めませんが、algorithm=MD5 となっています。
しかし、Digest認証は現実algorithmとしてMD5しか対応していないので、決め打ちでも動くと思います。

現実にネゴシエーションしなければならないのは、チャレンジ(nonce)ですが、これも上記のレスポンス例にnonce=として記載されています。チャレンジレスポンスというからには、毎回チャレンジを変えたいところですが、現実には固定になっていることが多いようです。
この問題を含め、Digest認証にはリプレイ攻撃対策などの様々なものがありますが、それらの目的については、上記の3番目の記事を参照ください。

Comments

[shum]

なるほど。
チャレンジレスポンス認証とDigest認証を絡めた説明は、探しても見つけられなかったので大変参考になりました。(私の前提知識不足ですが)

認証方式や攻撃対策についてはまだまだ知らないことが多そうなので勉強します。
この度はありがとうございました。