rm /blog

IT系技術職のおっさんがIT技術とかライブとか日常とか雑多に語るブログです。* 本ブログに書かれている内容は個人の意見・感想であり、特定の組織に属するものではありません。/All opinions are my own.*

パスワード議論(エラーチェックについて)

仕事で担当しているのは基本的に業務システムがメインだが、
いくつかの例外を除いていずれも「ログイン画面」が存在していて
ユーザー名(ユーザーID)とパスワードを入力してシステムにログインしてから業務を行うタイプのものがほとんどだ。
担当してきた業務システムを見るに、この「パスワード」に関してはシステムによって様々な考え方が存在するらしい。


 

 
ただ、いずれのシステムにおいても一般的な考え方として、
”ログイン失敗に関するエラーメッセージはあまり詳細に伝えない”というのが、システム設計の考慮の土台に存在するようだ。
というのも、ログイン画面(ユーザー名とパスワードの2項目だけが入力項目として存在する画面)におけるシステム側のエラーチェックロジックとしては

  • ユーザー名未入力
  • ユーザー名の入力はあるがシステム管理上有効ではない(存在しない)
  • パスワード未入力
  • システムが管理しているユーザー名のパスワードと画面で入力されたパスワードが一致しない

等、ぱっと考え付くだけでこのようなエラーチェックロジックが存在するが、
そのすべてにおいて、例えば「ユーザー名は合ってるけどパスワードが違うよ」等とエラーチェックで教えてしまうと
悪意を持った利用者に情報を余計に与えてしまうことになりかねない。
このため、ログイン失敗に関するエラーメッセージはいずれの場合も共通して”ログイン失敗”の旨のみ端的に伝えるエラーメッセージが好ましい。
こういう考え方に基づくらしい。
これは新人に近いころ、実際にシステム設計の打ち合わせに参加してそのような話が出て、「そういうものなんだ」と感心した記憶がある。

とはいえ、社内システム等においては、
ネットワーク上社内LANのみで公開するようになっていて外部からの侵入ルートが物理的に存在しない場合もあり、
そういうケースにおいてまでこのような考慮が必要かというのも少しばかり疑問には思う。
(社内に悪意を持った人間がいることを事前に防止する必要性を感じている…ということか…?)
まあベネッセの情報流出の件もあるから考え方の方向性に間違いはないだろうし、
実際に複数のエラーチェックロジックを実装するとなると
その分設計・製造・テスト各工程の工数(費用)も(微妙ではあるだろうが)かさむことになるので、
不要なものをシステムとして用意しないという意味でもこの考え方の方が正しいのだろう。



エラーメッセージとしてユーザーに伝えはしないものの、
上記に挙げた「エラーチェックロジック」はいずれも内部的には実装することになるのだが、
個人的な体験談を言うと上記に加えて”パスワード有効期限内かどうか”というのを実装することがよくある。
・最後にパスワードを変更してから○日経過していたら、ログイン成功してもログイン直後にアラートでその旨伝える(警告)
・最後にパスワードを変更してから△日経過していたら、ログイン成功した場合強制的にパスワード変更画面に遷移させる
↑こういう感じのものだ。

結果的に”ログインさせてしまう”ので、上記に挙げた「ログインそのものが失敗」とは性質が異なる。
要するに、悪意ある利用者云々における防止策ではない。
よってこの目的は、利用者のセキュリティ認識に対する注意喚起と意識改善といったところにあるように思う。

この処理は、ぶっちゃけると私の会社の社内システムによく実装されているものだ。
この考え方を踏襲して、実際にシステム構築する際にも同じ処理を提案することがあるが、
実体験からするといくつかのシステムにおいてこの考え方は不評である。
業務システムの目的は、ログインにあるのではなく、当然ログインした先にあるのであって、
ログイン時点で足止めされることは業務システムの本意ではない。
たかが数秒の流れだろうが、ログイン部分であーだこーだ言われるのはシステム利用者から見ても鬱陶しいのだろう、
というか実際私が鬱陶しいから多分間違いないと思う。

自社システムによくあるということを踏まえると、
”SEという職種である以上はパスワードの定期的な変更を行うように”という会社からの無言の指示であると受け取るべきなのかもしれない。
そう考えたら、この処理はますます、エンドユーザーに用意する仕組みではないと感じる。
設計し、レビューを経て、実装・テスト・お客様受入を経た以上はちゃんとしたシステムの仕様の一部なので、
それを変更することは仕様変更になる。要するに改修のための費用が掛かる。
この手の、業務システムの果たす「業務」以外の、共通部分や操作性等に関する課題は、
「鬱陶しくても、直すのにお金がかかるならまあいいか…」という考えになることが多いだろう。



パスワードに関しては、使用する文字種がシステム側で指定されているケースも多々存在する。
入力された文字列をもとに、「安心度(あるいは危険度)」をリアルタイムで測って色等でユーザーに伝える機構もよく見かける。
いくつかのシステムに触れてきた限りでは、英数字使用6桁以上というのがざっくりとした基本ルールになっているようだ。
よって、最低限アルファベットと数字を組み合わせるようなパスワードを要求されることが一般的と感じる。
この中で、「記号」に関してはシステムによって採用の程度が違う。
個人的な感覚では、比較的採用されにくい傾向にあるらしい。
記号とは、例えば"@"や"!"等のものだ。
正直に言うと個人的には使いたいのだけど、使えないというなら仕方がない。

こういった文字種限定の仕様に関しては、
主にパスワード変更画面で専用のエラーチェックロジックとエラーメッセージが用意されていることが多い。
ログイン失敗時には、失敗理由を詳しくエラーメッセージでユーザーに返却しないが、
パスワード変更画面での変更操作においては使えない文字種をきちんとユーザーに伝えるということだ。
まあ、考えてみれば当然である(パスワード変更画面はログイン後に使用する画面だから)。

残念なことに担当していたシステムのいくつかに、このエラーロジックをログイン画面にも実装してしまったため
ログイン画面ですらこのような文字種限定のエラーチェックとそのエラーメッセージが出てしまうものがあった。
これは上記の”ログイン失敗時のエラーメッセージを曖昧にする”とは著しく反する内容だ。
文字種のチェックはサーバサイドに行かずとも、JavaScriptでクライアント側でチェックができるため、
こういうことをしたくなる気持ちもわからんでもない(というか実際作ったシステムであった…)
とはいえ、切ないものである。
特別何か言われたわけではないのでそのままだが、あまりよろしくはないだろう。
通化してる部分もあるから直すの大変なんだけどね。



パスワード一つとっても、そのチェックの形式は様々だ。
業務システムにおいては、注力するほどの箇所でもないので(業務仕様の設計に注力すべき)、
あまり深く考えていない部分でもあるが、客観的に見ると深堀すべき点がいろいろある。
学んでいかなければなるまい。