前回はパスワード登録・変更等におけるエラーチェックに関していろいろ個人的な見解を述べたが、
少し違う方針の「エラーチェック」にパスワードの世代管理の考え方が存在する。
要するに”変更しようとしたパスワードは昔使ったことあるから変更できないよ”というやつである。
管理が何世代に及ぶかにもよるが、個人的にはこれも鬱陶しい仕様の一つになっている。
こういうパスワード世代管理のチェックにおいて、最も単純なのは「１世代前のパスワードに変更できない」というやつであろう。
現在のパスワードと、変更しようとしているパスワードを比べて、一致していればNGというものだ。
パスワードの「世代管理」の考え方としては、普通に考えるとユーザー別にパスワードの変更履歴を持つ必要があるが、
こと「１世代」に限定する場合は変更履歴専用のデータを持つ必要がない。
（将来的な拡張性を考えて…とかいう理由で持つこともあるかもしれない）
よって、「世代管理」の中でも特殊な部類に入ると思う。
世代が２以上になると、現在のパスワードとは別に、現在になる前のパスワードを別に保持しておく必要がある。
システム上明確な制限が決められていれば横持ちでも構わないだろうが、
汎用性があるのは世代番号なんかを付与して縦持ちする構造だろう。
| 案 | 例 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 横持ち案 |
↑KEYはユーザーIDで、現在パスワードを含め過去４つのパスワード情報を同一レコード上に保持する。 変更する度、「ｎ世代前パスワード」の値を「ｎ＋１世代前パスワード」にスライドする仕組み。 逆に、カラムを追加しない限りは（この例でいうと）４世代より前のパスワードは保持できない。（捨てられる） |
||||||||||||||||||||||||
| 縦持ち案 |
↑ユーザーIDと世代番号でKEYとなり、履歴情報を管理する仕組み。 「横持ち」案に比べて、テーブル構造の変更がなく世代の管理数を変更できる仕組みだ。 ただしテーブルスペースの関係もあるので、無制限に管理するわけにもいかないはずで、 システム上なんらかの管理上限は設けることになるだろう。 |
||||||||||||||||||||||||
このパスワードの世代管理の仕組みは個人的なことをいうと鬱陶しくて仕方なく、
世代管理数＋１だけ変更してまたもとのパスワードに戻すという作業を毎回実施している。
⇒世代管理数１なら「現在パスワード」しか保持しておらず、現在パスワードがAならA⇒B⇒Aという変遷をたどってまたAにしている、という意味である。
長く使っていると、慣れ等により、パスワードの入力を無意識に行うことがある。
そうなると、上の例でいえばA⇒Bの変更直後は無意識にAをうってしまい、「パスワードが違う」と怒られてしまう。
こういった経緯から、わざわざA⇒Bに変更した後またAにするという作業を即座に行って、無意識入力ができるAは結果的に変えないようにしている。
ただ、これがセキュリティの意識として正しいかといわれるとそうではないことも（一応）理解している。
パスワードの変更契機がユーザーの操作だけに依存する（ユーザーが変更をかけようとしない限りシステムから変更を即されることはない）場合には、
この仕様がそれほど鬱陶しく感じることはないように思うのだが、
前回の話に合った「定期的に変更」と併用されるとこの仕様に鬱陶しさを感じるようになると思う。
ユーザーが自ら変更しようと考えたかどうかというのがポイントなのか。
世代管理数にも寄るが、定期的に変更を行うことがシステム利用制限となり、使用できるパスワード候補がどんどんなくなっていくことも一つの不満要素といえる。
⇒手動操作が入るだけで定期バッチ処理のようなもの、と捉えることもできるのか。
例に漏れずこの仕様も自社業務システムでよく採用されているように思う。
定期変更との併用で、パスワード変更を強制されるとものすごく鬱陶しい。
そのうえ世代管理の仕組みにより、前回使用パスワードにはできないのだ。
うちの会社は何故そこまでしてパスワード変更管理を徹底したいのだ。
正直納得できない。
一般的な考え方なのだろうか。
SE故にパスワード変更を徹底するようにという意識改善策なのだろうか。
パスワードそんなに変える必要ある？
パスワードの世代管理の仕組みだって、そんなに難しくないが実装の手間は間違いなくかかるであろう。
うちの会社も、そんなのに手間かけるくらいならもっと別に費用と人手を割くところがあるだろう
と感じてしまうのである。
