上の続き

技術

# id:sshi 『ども。トラックバック先のsshiです。一点だけ。
>PasswordDigest = MD5( MD5( Password ) + Nonce )
>Digest認証の場合、サーバにパスワードを平文で保存する必要がないんですね。MD5(Password)を持っとけばOK。|
(これは少しおかしい気もしますが)そうだとしても、MD5(password)が結局生パスワードと同じことになりますよね。クライアントはMD5(password)だけ持ってれば認証できちゃうわけだし。』 (2006/03/31 04:14)

その通りですよね。。何言ってるんだろう自分。

# id:sshi 『すこし訂正します。
(MD5値を使って)ダイジェスト認証するものと、SSL+Basic認証するものを使いわけておけば、MD5値が漏れてもアクセスされるのは前者だけで後者へのアクセスは防げるかもしれませんね。気がついてませんでした。(また適当なこといってるかも)』

データを流出させたサービスAと、サービスAのユーザが同じパスワードを使っているサービスBがあった場合、

  1. サービスA 認証方式a
  2. サービスA 認証方式b
  3. サービスB 認証方式a
  4. サービスB 認証方式b

生のパスワードがDBに書いてある場合、DBデータが流出すると、1,2,3,4全てで認証が通ってしまう。

認証方式aがDigest認証で、DBにハッシュが書かれている場合、DBデータが流出すると、1,3は認証が通ってしまう。認証方式が異なる2,4は通らないかもしれない。 (追記) 3も普通は認証が通らないそうです。sheepmanさんのコメントをご覧下さい。

認証方式aがBasic認証で、DBにハッシュが書かれている場合、DBデータが流出しても、1,3は認証が通らない。2,4は流出したハッシュを送信するような認証方式でなければ大丈夫。

これとは別に、盗聴への対策が必要。なのでやっぱり、HTTPS+Basic認証(生で送信)が安全ということになる。

逆に言うと、DBデータに(認証されるのを防ぐ目的で)ハッシュを格納する場合、SSLを使わざるを得ない。

SSLが使えない場合に、通信経路とDBデータのどっちを守るべきか、という話で、通信経路の方を守るのが正しい選択ということかなー。

以下の記事が参考になります。