がるさんから以下のコメントをいただきましたので、トラックバックという形で意見を述べさせていただきます。
コメントありがとうございました。
どもです。がるです。
んっと…
http://d.hatena.ne.jp/gallu/20060303/p1
で同じような考察をして違うところに落としているのですが、ちと感想/反論などいただけるととてもうれしいです。
私の記事では、パスワードに設定できる最大桁数が異常に短く（１０桁）設定されている事が気になり、「１０桁に制限しなくてはいけないなら、ハッシュで持てば良いのに」という感想が発端となり書きました。
「現在用いてる一方向ハッシュ関数が脆弱になったので違うハッシュ関数に置き換えたい。さぁどうする？」
通例「やらない」とかいう物騒な選択か、或いは「全ユーザのパスワードを全部発行しなおして通知しまくり」という力技に頼る必要が出てきてしまいます。
んじゃ「どうせいっちゅうねん」って話なのですが。
一つに「単純に暗号化してぶち込む」手法があります。
鍵を抜かれるとNGなのでこの部分が最大懸念材料になりますが。そこさえクリアできれば、暗号方式を変えようが鍵換えようが、基本的に「内部処理」で片付きます。テーブルは、一端「別テーブル作って」、あとでスイッチングで切り替えてもいいですしねぇ。手法は色々。
ただしこの場合「鍵を守る」ことが限りなく重要にはなりますが。
暗号の場合、DBのフィールドLengthが不安定になるのも問題。CBCモードでやると、どうしてもIVまで入り込むので、ある程度の長さが必要になっちゃいますし。
この記事でも書かれている様に、ハッシュで持ってしまうと、復号できないため、ハッシュ関数が変わったとき、システムの中で閉じた対応ができないという点でめんどくさいし不利です。
そして、暗号化はその点で有利ではあります。
ただ、その反面、その気になればシステム管理者がパスワードを覗き見できてしまうわけです。
もし覗き見はしなかったとしても、いざ事件が起きたその時に、「パスワードを知り得る者」として疑われる理由になってしまう可能性にはなります。
その点だけで暗号化で格納しておく事によるハンドリングのし易さ等の利点が吹き飛んでしまうと思っています。
余談ですが、ハッシュ関数を変更する際に、全ユーザに対して、パスワードを全部発行しなおし、その後ユーザ自身に初期パスワードを変更して貰うというのは、一見、ユーザにとってもめんどくさい処理ではありますが、副作用として「ちゃんと対応していますので安心してください。」という安心感をユーザに与えるためのアピールにはなるかな。
だったら、ユーザも、そのめんどくささを受け入れてくれるかな。
なんて楽観視をしております。
余談は置いておくとしても、
いざという時、誰もが他人のパスワードを知り得ない状況を作っておきたいので、
パスワードはやはり復号可能な暗号ではなく、ハッシュで格納しておきたいなぁと思います。
以上、私の立場における感想です。
