生パスワードDB記録と、ハッシュについての議論のつづき

技術

# あらいしゅんいち 『ああ、そういう意味でしたか。それは現実的には全く問題がないと思っていたのですが。どういうときに問題になるとおもうのですか？ データベースにアクセスできる人は、自由にシステムを使える人であるはずなので、どうせ自由にログインできるとおもうんですが。

どういう場合に問題になるのかは、自分も疑問だと思います。id:sshiさんの記事でその議論がされています。

ただ、SQLインジェクションなんかでパスワード部分が漏れてしまい、そのDBに大した価値がなくて、認証後に利用可能になる(例えば特定のタイミングでの)別サービスとの通信に価値があるような場合は、あるかもしれないなーと思いました。

あとは、パスワードが特定のDBサーバに格納されていて、そのDBにだけSQLインジェクション脆弱性がある。他のDBにはアクセスできないけれど、認証を通してHTTPS経由でデータを引き出せてしまう。攻撃者はパスワードを書き換えるとバレてしまうので、ひっそりプライベートな情報を収集しつづける、みたいなシナリオです。

例えばmixiの非公開の日記やメッセージが、1ヶ月分密かに収集された挙句、個人情報とともにWinnyネットワークに流される、とか(もちろん別にmixiに脆弱性があるという話ではなくて例えばの話です)。

ともあれ体系を二つにすれば解決できそうです。上のDigest認証とは別に、0. hash(password,salt1) = hashed1, hash(hashed1,salt2) = hashed2という計算をして、DBにはhashed2, salt1, salt2だけを記録しておき、1.ユーザにまずsalt1を提示し、2.ユーザがhash(password + salt1)を計算し、hashed1をサーバに送る、3.システムはhash(それ + salt2)を計算し、DBのhashed2と照合する。
こうしておけばpasswordないしhashed1は、hashed2からは簡単に計算できないので、真のパスワードを知っている人しかhashed1を提示することができなくなりそうです。どうですか？
ここまでやるなら素直に公開鍵やSSLをつかっちゃったほうがいいような気がしますけど。』 (2006/04/03 10:33)

あらいさんがおっしゃってるのは、原理的にはBasic認証と同じだと思います。生のパスワード(hashed1)を送って、サーバでハッシュを計算して、hashed2と比較する。salt1、salt2は共に固定なので、hashed1も毎回固定です。リプレイ攻撃に耐えられないですよね。

体系を2つにするというのは、よくわからないのですが、Digest認証とBasic認証の一長一短の認証を2つ組み合わせてもニ長ではなく二短になってしまうような気がします。

-盗聴漏洩
Basic認証弱強
Digest認証強弱