んっと。会員制のサイトであれば、大抵の場合はDB(ないしテキストファイル)で、ユーザIDとパスワードを持つと思うのですが。
これを「どうやってもつか」への考察。
………困ったことに「これだ」と思えるものがありません(苦笑
通常、MD5などの「一方向ハッシュ関数」を用いることが多いのですが(MD5だめだめだよねぇとかいう話はおいておくとして。なにせ、MD5は「MaじでDaめになる５秒前っていうかもうDame？」の略ですから(笑))。
一方向ハッシュ関数は、サイズなどでの利点がある反面、常にコリジョン(衝突性)の危険が考えられます。まぁ、理論上「ほぼパスワードlengthを無規定に近いところに持ち込める」ってのは有利だと思うのですが。
もう一つ。「現在用いてる一方向ハッシュ関数が脆弱になったので違うハッシュ関数に置き換えたい。さぁどうする？」
通例「やらない」とかいう物騒な選択か、或いは「全ユーザのパスワードを全部発行しなおして通知しまくり」という力技に頼る必要が出てきてしまいます。
んじゃ「どうせいっちゅうねん」って話なのですが。
一つに「単純に暗号化してぶち込む」手法があります。
鍵を抜かれるとNGなのでこの部分が最大懸念材料になりますが。そこさえクリアできれば、暗号方式を変えようが鍵換えようが、基本的に「内部処理」で片付きます。テーブルは、一端「別テーブル作って」、あとでスイッチングで切り替えてもいいですしねぇ。手法は色々。
ただしこの場合「鍵を守る」ことが限りなく重要にはなりますが。
暗号の場合、DBのフィールドLengthが不安定になるのも問題。CBCモードでやると、どうしてもIVまで入り込むので、ある程度の長さが必要になっちゃいますし。
残念なことに、私は「正解」を知りません。
ただ、どちらも一長一短だと思っているので。せめて「状況に合わせた」提案が出来ないかなぁって思ってたりはするです。
