SYSTEM DEVELOPMENT

STUDY GROUP

ダイジェスト認証

あけましておめでとうございます。OYです。
開発側に入ってからもうすぐ半年になるのでしょうか。今年も精進してまいります。
早速ですが本題へ。
前回紹介したベーシック認証はセキュリティ面においてお世辞でも優れているとは言えないものでした。あれでは表向きな用途のシステムの認証としては使い物になりません。
今回はベーシック認証の弱点を十分に克服しているダイジェスト認証について解説します。
ここで言うダイジェストとは暗号学的な名称でハッシュ値のことを指します。その名の通り、この認証はこれから述べる方法によってハッシュ値を生成して情報のやりとりを行います。
ベーシック認証にて、最初のリクエスト(認証情報なし)を受け取ったサーバはクライアント側に認証領域と認証方法の提示を行っていましたが、ダイジェストではこれらに加え、nonce、qop、algorithmを提示します。
WWW-Authenticate : Digest realm=”secret”,nonce=”aaaaa”,qop=”auth”,algorithm=”MD5″
nonce = ランダムな文字列
qop = “auth” or “auth-init” ※基本はauth。auth-initはハッシュ生成時にボディも含める
algorithm = “MD5″ ※ハッシュ生成アルゴリズム。後述するが、MD5を利用するのは推奨しない。
クライアントはこれらの情報をもとにハッシュ値の計算を行うのですが、クライアント側も計算に必要なパラメータをいくつか用意します。
cnonce = ランダムな文字列
nc = 回数
url = コンテンツURI
method = “get” or “post”
計算式:
A1 = username : realm : password
A2 = method :  url
response = MD5( MD5(A1) : nonce : nc : cnonce : qop : MD5(A2) )
ユーザが認証情報を入力した後、クライアントは上述の計算を行いリクエストを送ります。
Authorization : response=”計算結果”,realm=”secret”,nonce=”aaa”,cnonce=”bbb”,nc=1,….(省略)
※パスワードを除いて、計算に必要な情報をカンマ区切りで送信している。
サーバ側では、あらかじめMD5(A1)が保管されており、クライアントが送った計算情報と合わせてresponseの再計算を行います。
この計算結果が、クライアントが送ったresponseと一致していれば認証成功となります。



要約すると、ダイジェスト認証は「nonceとcnonceがリクエストごとに変化する(reponseが常に変化する)」ことや、「そもそもハッシュ計算のアルゴリズムが強固である」ことで安全性が保証されているということになります。
なんだこれめんどくさっ!って思ったら、(使用しているアルゴリズムの脆弱性がまだ発覚してないのであれば)単純にA1にハッシュ関数を掛けるだけでもまあ十分だと思います。
なお、ここの例で用いたMD5は実は突破方法が確立してしまっているのでSHA-256のようなさらに強固なアルゴリズムを利用することを推奨します。

menu