パスワードの話。

ID／パスワードの入力を求めるシステムは多いと思いますが、パスワードはどういう値を設定するべきか、という話ではなく、システムを作る側の人間としてパスワードをどう扱うのが良いのか、という話です。

システム的にはID／生パスワードをDBに突っ込んで、認証時にID／生パスワードをキーにSQLを発行して該当レコードのありなしで判定するのが一番手っ取り早いですが、生パスワードをそのままDBに入れるってのはセキュリティ的にどうなのよ？と思います。

以前、某カード会社のポイント交換システムに携わってたときの話ですが、本番DBに接続できれば100万人超のID／パスワードを簡単に見ることが出来てしまいました。クレジットカードのポイントを金券や商品に交換できるシステムなのに。これが例えば、明確な悪意を持った人間が、本番DBへのアクセス権限を持っていたら？

そもそも本番DBへの接続は限られた人員に絞られることが当然ですし、こういうリスクは言い出したらキリがありませんが、パッと見でパスワードが分かるような作りになっているのはどうなんだろうと。せめてそこは何らかの対策を講じておくのが技術者としてあるべき姿なんじゃないかな〜と思う訳です。

で、自分がよくやるのは、パスワードをMD5で不可逆性をもったハッシュ値に変換してDBに突っ込む方法です。MD5は理論的な脆弱性が発見されているので、100％安全とは言えない状況ですが、生パスワードをそのまま扱うよりかは幾分マシだろうとこの方法を採用することが多いです。

ちなみにMD5は2004年にクラック可能という報告があり、2007年に実際にクラックされたようで、CRYPTRECの政府推奨暗号リストから外されています。（推奨はSHA-256以上）
http://www.win.tue.nl/hashclash/SoftIntCodeSign/

更に脱線して、2008年時点でSSLの証明書にはMD5が使われていましたが（現在はどうなっているか知りません）、200台のPS3で偽の証明書を作ることに成功したとか。PS3スゴイな。
http://jp.techcrunch.com/archives/20081230md5-collision-creates-rogue-certificate-authority/
Googleなどでハッシュ化された文字列データを検索すると元の文字列が見つかるという話もあるので、いい加減MD5には見切りを付けた方が良いかもしれません。

で、不可逆なハッシュ値として次点の候補に挙がるのはSHA-1。ただしSHA-1は2005年くらいに中国の研究者によってセキュリティを破る方法が発見されたという発表がありました。
http://www.computerworld.jp/news/sec/11541.html
これらの発表を受けて、アメリカ政府や大手企業ではSHA-1は使用不可としているところが多くあるらしいですが真相不明です。また、上記の論文も探してみましたが見つからず。誰か知っている方教えてください。

本気で対策をするならSaltがベストだと思いますが、そこまで求められるシステムじゃないしな〜ということであんまり使いません。

結局のところコストやシステム規模、メリットデメリットを勘案してどうするか決めましょうっていう話になるんですが、金銭や物が絡まなかったり、純然たる社内システムだったりならば生パスワードのまま扱うのも当然ありだと思います。ただ、Javaの場合だとcommons-codecを使えば簡単にハッシュ変換が出来る（MD5、SHA-1、SHA-256、SHA-384、SHA-512に対応）ので一手間加えておくことで後々役に立つかもしれません。開発中にパスワード忘れてDB覗いても分からなくてムキーってなりますけど。

暗号技術入門-秘密の国のアリス