医者の不養生

システムのワークフローを定義して、実装して、納品する。

その実、プロジェクトのワークフローは定義されていない。

FacebookTwitterHatenaTumblr共有

良いも悪いも納得させるには理由が必要だ

「こっちの方が良いと思うんだよね。」

「それじゃ駄目だよ。」

何故そう思うんだ?

周りを納得させるには理由が必要だ。

メリットを並べたて、デメリットを並べ立て、実績があるなら実績も加味して、これが良い、これが悪いを決めても遅くは無い。

でもね。理由は無いけど、良いと思う。悪いと思う。ってのは重要で、一つのアラームなのかもしれないんだ。もちろん、そうではないのかもしれない。

だから、どうしてそう思うのかを頑張って周囲に説明して欲しい。

じゃないと、自分だけが気づいている何かを伝えることが出来ないから。

プロジェクトを推進する上で決められたルールは守れ

設計規約

コーディング規約

作業のワークフロー

もろもろ・・・

ルールは守れ仕事なんだから。

ルールに改善の余地があっても、勝手に適用するな。

まずは相談からだ。

相談して改訂されてから適用しろ。

ルールは守れ仕事なんだから。

金貰ってるんだろ。

「パスワードはどうやって持つ?」への感想

がるさんから以下のコメントをいただきましたので、トラックバックという形で意見を述べさせていただきます。

コメントありがとうございました。

どもです。がるです。

んっと…

http://d.hatena.ne.jp/gallu/20060303/p1

で同じような考察をして違うところに落としているのですが、ちと感想/反論などいただけるととてもうれしいです。

私の記事では、パスワードに設定できる最大桁数が異常に短く(10桁)設定されている事が気になり、「10桁に制限しなくてはいけないなら、ハッシュで持てば良いのに」という感想が発端となり書きました。

「現在用いてる一方向ハッシュ関数が脆弱になったので違うハッシュ関数に置き換えたい。さぁどうする?」

通例「やらない」とかいう物騒な選択か、或いは「全ユーザのパスワードを全部発行しなおして通知しまくり」という力技に頼る必要が出てきてしまいます。

んじゃ「どうせいっちゅうねん」って話なのですが。

一つに「単純に暗号化してぶち込む」手法があります。

鍵を抜かれるとNGなのでこの部分が最大懸念材料になりますが。そこさえクリアできれば、暗号方式を変えようが鍵換えようが、基本的に「内部処理」で片付きます。テーブルは、一端「別テーブル作って」、あとでスイッチングで切り替えてもいいですしねぇ。手法は色々。

ただしこの場合「鍵を守る」ことが限りなく重要にはなりますが。

暗号の場合、DBのフィールドLengthが不安定になるのも問題。CBCモードでやると、どうしてもIVまで入り込むので、ある程度の長さが必要になっちゃいますし。

がるの健忘録 – パスワードはどうやって持つ?

この記事でも書かれている様に、ハッシュで持ってしまうと、復号できないため、ハッシュ関数が変わったとき、システムの中で閉じた対応ができないという点でめんどくさいし不利です。

そして、暗号化はその点で有利ではあります。

ただ、その反面、その気になればシステム管理者がパスワードを覗き見できてしまうわけです。

もし覗き見はしなかったとしても、いざ事件が起きたその時に、「パスワードを知り得る者」として疑われる理由になってしまう可能性にはなります。

その点だけで暗号化で格納しておく事によるハンドリングのし易さ等の利点が吹き飛んでしまうと思っています。

余談ですが、ハッシュ関数を変更する際に、全ユーザに対して、パスワードを全部発行しなおし、その後ユーザ自身に初期パスワードを変更して貰うというのは、一見、ユーザにとってもめんどくさい処理ではありますが、副作用として「ちゃんと対応していますので安心してください。」という安心感をユーザに与えるためのアピールにはなるかな。

だったら、ユーザも、そのめんどくささを受け入れてくれるかな。

なんて楽観視をしております。

余談は置いておくとしても、

いざという時、誰もが他人のパスワードを知り得ない状況を作っておきたいので、

パスワードはやはり復号可能な暗号ではなく、ハッシュで格納しておきたいなぁと思います。

以上、私の立場における感想です。

パスワードの桁数

ミクシなどがそうだけど、たびたび

「パスワードは10桁以内でよろしく。」

というシステムに遭遇する。

なんでパスワードを制限されなくちゃいけないのだろうか。

パスワードをそのまま格納しているのか、もしくは復号可能な形式で格納しているのか。

たいてい、そういうところに限って、パスワード忘れた時の対処が、

現在のパスワードを教えてくれる事になっている。

設定しなおしや新パスワードの発行ではなくである。

その対処もどうなんだろうかと思う。

逆に「パスワードを教える」というふざけた仕様になっているから、

ハッシュではなく復号可能な形で格納する必要があり、

パスワードの最大桁数を決定する必要があったのだろう。

パスワードの性質からすれば、最大桁数を制限されて得をする事などは何も無いのになぁ。

ついでに言えば、文字種の制限もしないで欲しい。

communication breakdown

現在は、昔に比べコミュニケーション不足であると言われがちだが、逆だと思っている。

現在ほど、コミュニケーション過多な時代は無いだろう。

コミュニケーションの形は時代とともに変わっていく。

コミュニケーション不足だという声は、そのコミュニケーションの形の移り変わりが見えていないという事と、自分以外のものとコミュニケーションを取る機会が増えた事により、コミュニケーションを取る上での問題がクローズアップされて見えるだけだろう。