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