JP4844106B2

JP4844106B2 - ユーザ認証制御のためのプログラム、方法及びコンピュータシステム

Info

Publication number: JP4844106B2
Application number: JP2005348836A
Authority: JP
Inventors: 勝行近藤
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2005-12-02
Filing date: 2005-12-02
Publication date: 2011-12-28
Anticipated expiration: 2025-12-02
Also published as: JP2007156675A

Description

本発明は、コンピュータシステムにおけるユーザ認証に関し、特にアカウントのロックアウト制御に関する。

ユーザ認証を行うコンピュータシステムにおいては、必ず悪意のユーザによる攻撃が想定される。そのため、この種のシステムにおいては、アカウントロックアウト機能が設けられていることが一般的である。アカウントロックアウト機能は、ログイン試行が短期間の間に何度か続けて失敗すると、攻撃と判断してログインが試みられたアカウントをロックアウトし、そのアカウントでのログインを認めないよう制御する機能である。攻撃に曝されたアカウントをロックアウトすることで、そのアカウントのパスワードが破られる危険性を低減できる。

このように、アカウントロックアウト機能はシステムへの不正侵入を防ぐ意味で重要な役割を果たすが、欠点もある。例えば、悪意あるユーザが他人のアカウントに対して適当なパスワードを用いてログイン試行を繰り返すことで、そのアカウントをロックアウトさせることが起こり得る。また、悪意のあるユーザによらなくとも、例えば一般のユーザが自分のユーザＩＤを間違って入力しログイン試行を繰り返すと、その間違ったユーザＩＤがたまたま他人のユーザＩＤに一致していた場合、後者がアカウントロックアウト状態となってしまう。

いったんアカウントがロックアウトされると、システム管理者などシステムの管理情報を操作する権限を持った人に要請してアカウントが利用可能な状態に変更してもらうまでは、ユーザは自分のアカウントでログインができなくなるため、正当なユーザが不自由を強いられる。

特にシステム管理者のアカウントがロックアウト状態となると、そのような解除操作を含めシステム管理上の様々な操作ができないため、大きな問題となる。これに対する対策として、システム管理者のアカウントはロックアウトしない設定とすることも考えられるが、こうすると逆にパスワードを破られるリスクが増大する。

特許文献１には、１つのユーザアカウントに対して複数のパスワードを設定可能とし、パスワードの不正入力回数が許容値を超えるごとに、ユーザに入力させるパスワードの個数を増やしていく方式が示される。

この方式の場合、１つ目のパスワードが破られても、２つ目のパスワードが破られない限り不正アクセスを防ぐことができる。しかし、１つ目のパスワードが破られた状態のまま、うっかりそのパスワードを変更せずに通常状態に復帰してしまった場合、その後の不正アクセスが容易になってしまうという問題がある。２つ目、３つ目のパスワードが破られ、それが変更されずにおかれると、不正アクセスのリスクが益々増大する。

特許文献２には、認証用のパスワードを変更するための第２のパスワードが設定可能な装置が示される。同文献の第９３段落に示されるように、この装置では、第１パスワードの入力間違いが所定回数続いた場合、当該ユーザアカウントを使用不可状態とし、その後ユーザから管理者へ連絡があった場合、管理者が第２パスワードを第１パスワードにコピーし、第２パスワードでのログインを認める。第２パスワードの有効期間は比較的短い期間（例えば一日）に設定され、その間にユーザが第２パスワードでログインし、第１パスワードを変更するように促す。

特許文献２の方式では、結局第１パスワードの入力間違いが続くとユーザアカウントがロックアウト状態になってしまい、第２パスワードを有効にするには、利用者が管理者に報告を行い、管理者がそれに応じて第２パスワードを有効にする操作を行う必要があった。

特開２０００−２５９２７６号公報特開２００４−１４５８９６号公報

本発明は、上記従来技術の課題の少なくとも一つに対する解決又は改善をもたらそうとしたものである。

本発明の１つの側面では、システムは、ユーザから入力された第１のユーザ認証情報に基づくユーザ認証において、第１の不正アクセス条件が満足された場合に、当該ユーザのアカウントの第１状態を認証情報要変更状態に移行させ、第１状態が認証情報要変更状態にあるユーザから正しい第１のユーザ認証情報が入力された場合に、第２のユーザ認証情報と、第１のユーザ認証情報に対応する第１の変更情報と、の入力をユーザに促し、ユーザから入力された第２のユーザ認証情報に基づき第２のユーザ認証を実行し、第２のユーザ認証において第２の不正アクセス条件が満足された場合に、当該ユーザのアカウントの第２状態を通常状態から認証情報要変更状態に移行させ、第２のユーザ認証が成功した場合に、第２状態が通常状態であれば、第１の変更情報を用いて第１のユーザ認証情報を変更してユーザにログインを許可し、第２のユーザ認証が成功した場合に、第２状態が認証情報要変更状態であれば、第１の変更情報による第１のユーザ認証情報の変更は行わずに、第３のユーザ認証情報と、第２のユーザ認証情報に対応する第２の変更情報と、の入力をユーザに促し、ユーザから入力された第３のユーザ認証情報に基づき第３のユーザ認証を実行し、第３のユーザ認証が成功した場合に、第１の変更情報を用いて第１のユーザ認証情報を変更し、第２の変更情報を用いて第２のユーザ認証情報を変更してユーザにログインを許可し、第３のユーザ認証が失敗した場合には、第１の変更情報による第１のユーザ認証情報の変更、及び、第２の変更情報による第２のユーザ認証情報の変更、を行わないまま、ユーザのログインを拒否する。

参考例では、システムは、第２のユーザ認証が成功した場合に、当該ユーザのアカウントの第１状態を通常状態へと復帰させる。

参考例では、システムは、前記第２のユーザ認証において第２の不正アクセス条件が満足された場合に、当該ユーザのアカウントの第２状態をパスワード要変更状態に移行させ、第２状態がパスワード要変更状態にあるユーザから第１及び正しい第２パスワードが共に正しく入力された場合に、第３のユーザ認証情報と、第２のユーザ認証情報に対応する第２の変更情報と、の入力をユーザに促し、ユーザから入力された第３のユーザ認証情報に基づき第３のユーザ認証を実行し、第３のユーザ認証が成功した場合に、前記第１の変更情報を用いて前記第１のユーザ認証情報を変更し、第２の変更情報を用いて第２のユーザ認証情報を変更する。

参考例では、システムは、第Ｎのユーザ認証において第Ｎの不正アクセス条件が満足された場合に、当該ユーザのアカウントの第Ｎ状態をパスワード要変更状態に移行させ、第Ｎ状態がパスワード要変更状態にあるユーザから第１〜第Ｎスワードのすべてが正しく入力された場合に、第（Ｎ＋１）のユーザ認証情報と、第Ｎのユーザ認証情報に対応する第Ｎの変更情報と、の入力をユーザに促し、ユーザから入力された第（Ｎ＋１）のユーザ認証情報に基づき第（Ｎ＋１）のユーザ認証を実行し、第（Ｎ＋１）のユーザ認証が成功した場合に、第１〜第Ｎの変更情報を用いて第１〜第Ｎのユーザ認証情報をそれぞれ変更する。

別の態様では、システムは、特別ユーザを登録し、登録された特別ユーザについて前記第１の不正アクセス条件が満足された場合には、当該ユーザのアカウントの第１状態をパスワード要変更状態とし、特別ユーザ以外のユーザについて前記第１の不正アクセス条件が満足された場合には、当該ユーザのアカウントをロックアウト状態とする。

以下、図面を参照して、本発明の実施の形態（以下「実施形態」とも呼ぶ）について説明する。

本実施形態のユーザ認証方法は、図１に示すように、インターネットやＬＡＮ（ローカルエリアネットワーク）などのネットワーク４を介してクライアント２に情報処理サービスを提供するサーバ６にて実行される。一例を挙げるならば、サーバ６は、ウェブサービスを提供するウェブサーバであり、この場合クライアント２はユーザのＰＣ（パーソナルコンピュータ）上で実行されるウェブブラウザである。もちろん、サーバ６がクライアント２に提供するサービスは、これに限定されるものではない。サーバ６は、他のサーバに対するユーザのログイン認証を代行するサービスを行うものであってもよい。

サーバ６は、図２に示すような認証モジュールを備える。すなわち、この認証モジュールは、制御部１０，画面生成部１２，認証部１４，パスワード更新部１６，第２パスワード検証部１８，及び認証データ保持部２０を備える。

制御部１０は、ユーザからのログイン要求に対する処理を制御する。特に、制御部１０は、各ユーザのアカウントについて、当該アカウントに対するログイン操作の試行回数、当該アカウントの現在の状態或いはモード(通常状態 / ロックアウト状態 / パスワード要変更状態)を基に、当該アカウントの状態の遷移を制御する。

ここで、ロックアウト状態は、（仮にユーザが正しいパスワードを入力したとしても）当該アカウントに対するログインが認められない状態であり、従来のアカウントロックアウト制御でのロックアウト状態と同じものである。通常状態は、ユーザが正しいパスワードを入力すればログインが認められる状態であり、従来のアカウントロックアウト制御におけるロックアウト状態の対立概念である。

これに対し、パスワード要変更状態は、本実施形態にて新たに導入した状態であり、ユーザのログインパスワードの変更が要求される状態である。本実施形態では、システム管理者などの特別なユーザをあらかじめサーバ６に登録しておき、その特別ユーザのアカウントについては、従来のアカウントロックアウト制御ならばロックアウト状態とされる条件（不正アクセス条件と呼ぶ。例えば所定数回続けてログイン試行が失敗するなど）が満足されても、ロックアウト状態とせずにパスワード要変更状態とする。パスワード要変更状態のアカウントに対してユーザからログインが試みられた場合、認証モジュールはそれを門前払いせず、ユーザに対してパスワードの変更を促す。このパスワード変更操作を認めるか否かを判定するために、ユーザには第２パスワードの入力を行わせる。なお、パスワード要変更状態の場合の処理を含む、本実施形態のユーザ認証処理の流れについては、後で詳しく説明する。

画面生成部１２は、制御部１０の要求に応じて、ログイン画面、パスワード変更画面、エラー画面などの各種画面情報を生成して返す処理を行う。

認証部１４は、制御部１０から渡されたユーザＩＤ（例えばユーザ名）とパスワードを、認証データ保持部２０が保持するデータと照合し、認証の成否を返す処理を行う。

パスワード更新部１６は、認証データ保持部２０が各ユーザごとに保持する認証用のパスワード（以下では、第２パスワードとの区別のために、第１パスワードと呼ぶこともある）を、制御部１０から渡された新しいパスワードに書き換える処理を行う。

第２パスワード検証部１８は、制御部１０から渡された第２パスワードが、認証データ保持部２０が各ユーザごとに保持する第２パスワード(認証用の第１パスワードを変更するためのパスワード)と一致しているかどうかを検証する処理を行う。

認証データ保持部２０は、システムに登録されている各ユーザについて、それぞれユーザ情報レコードを備える。１人のユーザのレコードは、図３に示すように、ユーザＩＤ、特別ユーザフラグ、第１パスワード、第２パスワード、ログインの試行回数、当該ユーザアカウントの現在の状態(通常 / ロックアウト / パスワード要変更)の情報を保持する。特別ユーザフラグは、当該ユーザが、ロックアウト状態にしない特別ユーザであるか否かを示すフラグである。システム管理者等のあらかじめ定められた者が制御部１０に対して特別ユーザを登録すると、そのユーザの特別ユーザフラグの値が「１」にセットされる。特別ユーザでないユーザ（一般ユーザと呼ぶ）のフラグは「０」である。図示の例ではユーザ"kondou"は特別ユーザであり、"hijikata"及び"okita"は特別ユーザではない。特別ユーザについては、パスワード要変更状態の時の第１パスワード変更のために、第２パスワードが登録される。これに対し、一般ユーザには、第２パスワードの登録は不要である。試行回数は、ユーザからのログイン試行の失敗の連続回数であり、例えば不正アクセス条件が満足されるかどうかの判定のために用いられる。不正アクセス条件としては、例えば、試行回数が許容値を超えたこと、などが例示できる。この許容値は、システム管理者等からあらかじめ設定されるものであり、特別ユーザと一般ユーザとで別の値にしてもよいし、また個々のユーザごとに別の値としてもよい。試行回数は、ログインが成功した場合に０へとクリアされる。また、最後のログイン試行失敗から所定の時間を経過した場合に、試行回数を０にクリアするようにしてもよい。試行回数をクリアする条件となる所定時間は、特別ユーザと一般ユーザとで別の値にしてもよいし、また個々のユーザごとに別の値としてもよい。

制御部１０、認証部１４、パスワード更新部１６及び第２パスワード検証部１８は、以上に例示した認証データ保持部２０内のデータを用いて、以下に詳細に示すログイン認証処理を実行する。

まず、図４を参照して、サーバ６の認証モジュールが実行する、一般ユーザに対するログイン認証処理を説明する。この処理は、ユーザがクライアント２を操作してサーバ６に対するログイン要求を発することにより開始される（Ｓ１０１）。例えばサーバ６がウェブサーバの場合、ログイン要求は、ユーザがクライアント２（ウェブブラウザ）に対し、サーバ６のログインページのＵＲＬを入力することにより、生成される。ログイン要求を受けたサーバ６では、画面生成部１２がログイン画面を生成し、これを要求元のクライアント２に提供する。ログイン画面は、例えばウェブページとして提供してもよい。ログイン画面には、ユーザＩＤと認証用のパスワード（すなわち第１パスワード）とを入力するための入力欄が含まれる。ユーザがクライアント２を操作してログイン画面にユーザＩＤ及びパスワードを入力すると、それらユーザＩＤ及び第１パスワードがサーバ６に送信される（Ｓ１０３）。サーバ６では、制御部１０がそのユーザＩＤ及び第１パスワードを受け取り、これらを認証部１４に渡してユーザ認証処理の実行を依頼し、その結果を受け取る（Ｓ１０４）。このとき認証部１４は、ユーザＩＤと第１パスワードのペアが認証データ保持部２０に保持されているものと一致するか否かを判定し、一致すれば認証成功の回答を、一致しなければ認証失敗の回答を制御部１０に返す。制御部１０は、当該ユーザＩＤが示すアカウントの現在の状態を認証データ保持部２０から求め、それが通常状態であるかどうかを判定する（Ｓ１０５）。通常状態であれば、制御部１０は、次に、認証処理の結果"result"が認証成功"OK"であるか否かを判定する（Ｓ１０６）。認証成功であれば、サーバ６はそのユーザのログインを認める。この場合、制御部１０は、当該ユーザの試行回数を示すカウント値"num"をクリアして０にし、サーバ６が提供するサービスのためのアプリケーション画面（例えば提供するウェブサービスのページ）をクライアント２に送信し（Ｓ１０８）、認証処理を終了する（Ｓ１０９）。

ステップＳ１０６で、認証結果が失敗と判定された場合は、試行回数"num"を１だけインクリメントし（Ｓ２０１）、その試行回数を許容値と比較する（Ｓ２０２）。試行回数が許容値を超えると、不正アクセス条件が満足されたことになり、制御部１０は、当該ユーザの状態をロックアウト状態へと変更する（Ｓ２０３）。試行回数が許容値を超えていなければ、制御部１０は画面生成部１２に命じて再度ログイン画面をクライアント２へと送らせる（Ｓ１０２）。

なお、ステップＳ１０５で通常状態でないと判定された場合は、当該ユーザアカウントはロックアウト状態であるということなので、制御部１０は画面生成部１２に命じてクライアント２にエラー画面を送らせる（Ｓ３０１）。エラー画面は、例えば当該ユーザがログイン不能な状態である旨を示すメッセージを示した画面でよい。また、システム管理者に連絡することで通常の状態に戻れるなど、状況に対する対処法をエラー画面に表示してもよい。

以上に説明した一般ユーザについての認証処理は、従来のアカウントロックアウト制御と同様のものである。

次に特別ユーザに対する認証処理の手順を、図５を参照して説明する。図５の手順において、ステップＳ１０１〜Ｓ１０９、及びステップＳ２０１〜Ｓ２０２の処理は、図４の手順と同じである。

図４の手順と異なる点は、まず、ステップＳ２０２にて、ログイン試行回数が許容値を超えたと判定された場合に、当該ユーザをロックアウト状態とする代わりに、パスワード要変更状態とすることである（Ｓ２０４）。

パスワード要変更状態のユーザがログイン要求を行った場合、通常状態のユーザの場合と同様のログイン画面が提供され（Ｓ１０２）、ユーザはそれに対してユーザＩＤと第１パスワードを入力する（Ｓ１０３）。制御部１０は、それらユーザＩＤと第１パスワードを認証部１４に渡してユーザ認証を行わせる（Ｓ１０４）。そして、この場合、パスワード要変更状態なので、ステップＳ１０５では当該ユーザの現在の状態が通常状態でないと判定され、制御部１０の実行する処理はステップＳ４０１へと移行する。

ステップＳ４０１では、制御部１０は、ステップＳ１０４で得られる認証結果が成功であるか否かを判定し、成功であれば、画面生成部１２に第１パスワード変更画面を生成させ、クライアント２へと送信させる（Ｓ４０２）。第１パスワード変更画面には、第２パスワードの入力欄と、変更した第１パスワードを入力する入力欄とが含まれる。ユーザがクライアント２を操作してそれら各入力欄に第２パスワード及び変更後の第１パスワードを入力すると、それがサーバ６の制御部１０に送られる（Ｓ４０３）。制御部１０は、そのうちの第２パスワードを第２パスワード検証部１８に渡して検証を依頼し、その結果を受け取る（Ｓ４０４）。このとき、第２パスワード検証部１８は、制御部１０から受け取った第２パスワードと、認証データ保持部２０が保持する当該ユーザの第２パスワードとを比較し、両者が一致すれば検証成功の回答を、不一致ならば検証失敗の回答を制御部１０に返す。

制御部１０は、第２パスワードの検証結果が成功であれば、当該ユーザの第１パスワードを、ステップＳ４０３で入力された変更後のパスワードへと変更するよう、パスワード更新部１６に命じる（Ｓ４０６）。これに応じ、パスワード更新部１６は、認証データ保持部２０に登録された当該ユーザの第１パスワードを、変更後の第１パスワードに書き換える。また制御部１０は、認証データ保持部２０が保持する当該ユーザの現在状態の情報を通常状態へと書き換え、試行回数"num"をクリアする（Ｓ４０６）。

なお、ユーザ認証が失敗したとステップＳ４０１で判定された場合は、制御部１０は当該ユーザの試行回数を１だけインクリメントし（Ｓ５０１）、ステップＳ１０２に戻る。

また、ステップＳ４０５で第２パスワードの検証が失敗したと判定された場合、図５の手順では、正しいユーザからのアクセスではないと判断し、制御部１０は画面生成部１２にエラー画面を生成させ、クライアント２に送らせる（Ｓ６０１）。

以上、実施形態の構成及び処理を説明した。この実施形態では、特別ユーザのアカウントはロックアウト状態とならず、当該ユーザが正しい第１パスワードと正しい第２パスワードを提示すれば、第１パスワードの変更操作が許される。そして、第１パスワードが変更されると、通常状態へと復帰できる。このようなことから、システム管理者等の特別ユーザのアカウントが攻撃や他人のミスなどで不正アクセス条件を満たしてしまっても、正しい特別ユーザがアクセスすれば通常状態へ復帰できるので、特別ユーザがロックアウトされるという従来の問題は解消できる。

また、本実施形態では、パスワード要変更状態となった特別ユーザのアカウントは、第１パスワードの変更操作を経てからでないと通常状態に復帰しない。不正アクセス条件が満たされた場合、攻撃が想定され、第１パスワードが破られた可能性を考慮する必要が出てくるため、第１パスワードを変更することがセキュリティ上好ましい。したがって、本実施形態のように、第１パスワードの変更操作をしないと通常状態に復帰しないようにすれば、第１パスワードをユーザに更新させることができるので、破られた可能性のある第１パスワードがそのまま残ってしまうという問題の発生を低減できる。

なお、図５の処理では、第２パスワードと変更後の第１パスワードの入力欄を１つの画面上に設けたが、この代わりに、まず第２パスワードの入力画面をユーザに提供し、これに対してユーザが正しい第２パスワードを入力した場合に、第１パスワードの変更画面を提供して変更後の第１パスワードを入力させるようにしてもよい。

また、図５の処理では、ステップＳ４０５で第２パスワードが正しくないと判定された場合、単にエラー画面をユーザに提供するだけであった。この方式では、例えば第１パスワードを破った攻撃者が第２パスワードを総当たりで調べる可能性が出てくる。

これに対する対策としては、一例として、第２パスワードの試行に対して許容回数を定め、試行回数が許容回数を超えた場合に、当該特別ユーザのアカウントをロックアウト状態としてしまう方式が考えられる。

ただし、この方式では、攻撃者により特別ユーザのアカウントがロックアウトされるという可能性が出てくる。これを避ける別の対策方式として、第１パスワードについての不正アクセス条件が満足された場合と同様の処理を、第２パスワードについての不正アクセスが行われた場合にも適用する方式がある。すなわち、この方式では、特別ユーザに対して第３パスワードを認証データ保持部２０に登録しておき、第２パスワードについての不正アクセス条件が満足されると、第３パスワードをユーザに入力させ、正しい第３パスワードが入力されると第２パスワードを変更する。ここでの不正アクセス条件は、第２パスワードの試行回数が所定の許容値を超える、等の条件である。また、ここで用いる許容値は第１パスワードの試行回数の許容値は独立した値であり、システム管理者等があらかじめ設定しておく。

図６にこの方式の処理手順を示す。なお、図６では、紙面サイズの都合上、図５の処理手順と共通する部分は図示を大幅に省略し、図５と相違する部分を中心に図示している。

図６に示したステップのうちステップＳ４０１〜Ｓ４０４までは図５の手順と同じである。図６の手順では、ステップＳ４０４の後、第２状態が通常状態であるか否かを判定する（Ｓ４０７）。この第２状態は、第２パスワードの保護のために導入した新たな状態である。第２状態は、「通常」と「パスワード要変更」の少なくとも２つの状態をとり得る。なお、区別のため、図４及び図５の手順に現れる現在のアカウントの「状態」のことを、以下では「第１状態」と呼ぶことにする。ステップＳ４０７で第２状態が「通常」であると判定されると、ステップＳ４０８に進む。

ステップＳ４０８は、図５の手順のステップＳ４０５と同じ処理であり、ステップＳ４０４による第２パスワードのチェック結果を判定する。ステップＳ４０８で第２パスワードが正しくないと判定されると、第２パスワードの試行回数"num2"をインクリメントし（Ｓ７０１）、その試行回数を許容値と比較する（Ｓ７０２）。試行回数が許容値を超えなければ、制御部１０は、ステップＳ１０２に戻って、ログイン画面をユーザに提供し、ユーザＩＤと第１パスワードの再入力を促す。一方、第２パスワードの試行回数が許容値を超えた場合は、制御部１０は、第２状態を「通常」から「パスワード要変更」へと遷移させ（Ｓ７０３）、ステップＳ１０２に戻ってログイン画面をユーザに提供する。

ステップＳ４０８で第２パスワードが正しいと判定されると、第１パスワードがステップＳ４０３で入力された新しいものへと更新され、アカウントの状態（第１状態）を通常状態に復帰させ、試行回数"num"をクリアして０にする（Ｓ４０９）。この場合、ユーザは、ステップＳ１０３で正しい第１パスワードを、ステップＳ４０３で正しい第２パスワードを、それぞれ入力したことになるので、正当なユーザと判断できる。そこで、制御部１０は、ステップＳ４０９の後、ユーザにアプリケーション画面を提供する（Ｓ１０８）。

ステップＳ４０７で第２状態が通常状態でないと判定された場合、第２状態はパスワード要変更状態である。この場合、制御部１０は、ステップＳ４０４のチェック結果を判定し（Ｓ８０１）、この結果第２パスワードが正しくないと判定された場合は、第２パスワードの試行回数"num2"を１だけインクリメントする（Ｓ９０１）。

ステップＳ８０１の判定で、第２パスワードが正しいと判定されると、制御部１０は、第３パスワードの入力欄と、変更した第２パスワードの入力欄とを含んだ第２パスワード変更画面を画面生成部１２に生成させ、この画面をクライアント２に送る（Ｓ８０２）。クライアント２でユーザがその画面に第３パスワードと変更後の第２パスワードを入力すると（Ｓ８０３）、制御部１０は第３パスワードが正しいものであるか否かの検証を実行する（Ｓ８０４）。この検証は認証データ保持部２０を参照して実行する。制御部１０は、この検証結果に基づき第３パスワードが正しいか否かを判定し（Ｓ８０５）、正しいと判定した場合は、認証データ保持部２０に登録されている当該ユーザの第１パスワード及び第２パスワードを、ステップＳ４０３で入力された新たな第１パスワード及びステップＳ８０３で入力された新たな第２パスワードへとそれぞれ変更し、第１状態及び第２状態をそれぞれ通常状態へと復帰させ、更に試行回数"num"及び"num2"をそれぞれ０へとクリアする（Ｓ８０６）。この場合、ユーザは、ステップＳ１０３で正しい第１パスワードを、ステップＳ４０３で正しい第２パスワードを、ステップＳ８０３で正しい第３パスワードを、それぞれ入力したことになるので、正当なユーザと判断できる。そこで、制御部１０は、ステップＳ８０６の後、ユーザにアプリケーション画面を提供する（Ｓ１０８）。

なお、図６の例では、ユーザが入力した第３パスワードがステップＳ８０５で正しくないと判定された場合、エラー画面をユーザに送り（Ｓ１００１）、更にステップＳ１０２に戻ってログイン画面を送る。このとき、当該ユーザのアカウントをロックアウトしてもよい。

図６の処理方式では、正しい第３パスワードを知っているユーザでないと第２パスワードも第１パスワードも変更できない。したがって、万が一第１パスワードと第２パスワードの両方が破られても、それだけでは第１パスワードを変更できないので、特別ユーザのアカウントの安全性が向上する。

また、この処理方式では、第２パスワードの不正アクセス条件が満足された場合において、ユーザが第１、第２、及び第３パスワードを共に正しく入力すると、第１及び第２パスワードが更新され、第１及び第２状態が通常状態へと戻る（ステップＳ８０６）。すなわちこの処理方式では、アカウントの状態が通常状態に復帰した時点で第１及び第２パスワードが変更されないまま残っている可能性を低減できる。

なお、図６の方式では、３段階のパスワードを用いたが、これを更に拡張することも可能である。例えば、４段階の保護にするには、第３パスワードの保護のために「第３状態」を導入すると共に、第３パスワードについても試行回数"num3"をカウントし、これが許容回数を超えると第３状態を「パスワード要変更」へと切り換えればよい。第３状態が「パスワード要変更」のときに、ユーザが第１〜第３パスワードの全てを正しく入力すれば、制御部１０が、第４パスワードと、変更した第３パスワードの入力を求める第３パスワード変更画面を提供し、ユーザにパスワード変更を促すようにすればよい。この場合、図６の手順に対し、ステップＳ８０４とステップＳ８０５の間に第３状態が「通常」か否かを判定するステップを追加し、この判定結果が「いいえ」となった場合の処理として、Ｓ８０１〜Ｓ８０６及びＳ９０１及びＳ１００１と同様の手順を追加し、更にステップＳ８０５の判定結果が「いいえ」となった場合の処理として、ステップＳ１００１に代えて、ステップＳ７０１〜Ｓ７０３と同様の手順を追加すればよい。この処理では、第４パスワードが正しく入力されると、第１〜第３パスワードが一括して更新されることになる。

一般化すれば、認証データ保持部２０には、特別ユーザについては第１〜第Ｍ（Ｍ≧Ｎ＋１。Ｍ，Ｎは自然数）までの各パスワードをあらかじめ登録しておく。また、それら第１〜第（Ｍ−１）の各パスワードを保護するための状態として、制御部１０は、第１〜第（Ｍ−１）状態を管理する。そして、第Ｎパスワードの試行について不正アクセス条件が満足されると、サーバ６は、第Ｎ状態をパスワード要変更状態へと切り換える。そして、第Ｎ状態がパスワード要変更状態であるときに、ユーザが第１〜第Ｎパスワードを全て正しく入力すると、第（Ｎ＋１）パスワードと変更後の第Ｎパスワードの入力を促す第Ｎパスワード変更画面をユーザに提供する。この画面に対して正しい第（Ｎ＋１）パスワードが入力された場合、認証データ保持部２０上の第１〜第Ｎパスワードを全て変更後のものへと更新する。

このような方式を採用すれば、セキュリティポリシー上安全と判断される段階まで、複数のパスワードにより多重的にアカウントを保護できると共に、それら複数のパスワードのうち、不正アクセス条件が満足されたもの（破られている可能性を考慮しなければならないもの）が変更されないまま残るリスクを低減できる。

なお、この方式では、ユーザは比較的複雑なパスワードを複数管理しなければならない。一般ユーザにこのようなパスワード管理を課すのは困難な場合もある。しかし、システム管理者などの特別ユーザであれば、そのような複数のパスワードを管理しても一般ユーザよりは負担が少ない。また限られた特別ユーザであれば、複数のパスワードのメモを金庫などに保管しておき、必要となった時に取り出して参照するなどといった運用も可能なので、実現は比較的容易である。

以上の例では、ユーザの認証情報としてパスワードを用いる場合を例示したが、パスワード以外のユーザ認証情報を用いる場合にも同じ枠組みが適用できる。

本実施形態のサーバ６は、以上に例示した各ユニット１０〜２０の機能又は処理内容を記述したプログラムを汎用のコンピュータに実行させることにより実現される。このプログラムは、可搬型の記録媒体に記憶された状態でユーザに提供されてもよいし、電気通信網を介したダウンロードによりユーザに提供されてもよい。なお、各ユニット１０〜２０は、必ずしも１つのコンピュータ上に実現される必要はなく、それら各ユニットが複数のコンピュータに分散され、それらが協調して上述の処理を実行してもよい。

実施形態が適用されるシステムの構成例を示す図である。サーバの認証モジュールの機能ブロック図である。認証データ保持部の保持するデータ内容の例を示す図である。一般ユーザに対する認証処理の手順を示すフローチャートである。特別ユーザに対する認証処理の手順を示すフローチャートである。特別ユーザに対する認証処理の手順の別の例の一部を示すフローチャートである。

符号の説明

２クライアント、４ネットワーク、６サーバ、１０制御部、１２画面生成部、１４認証部、１６パスワード更新部、１８第２パスワード検証部、２０認証データ保持部。

Claims

ユーザから入力された第１のユーザ認証情報に基づくユーザ認証において、第１の不正アクセス条件が満足された場合に、当該ユーザのアカウントの第１状態を認証情報要変更状態に移行させ、
第１状態が認証情報要変更状態にあるユーザから正しい第１のユーザ認証情報が入力された場合に、第２のユーザ認証情報と、第１のユーザ認証情報に対応する第１の変更情報と、の入力をユーザに促し、
ユーザから入力された第２のユーザ認証情報に基づき第２のユーザ認証を実行し、
第２のユーザ認証において第２の不正アクセス条件が満足された場合に、当該ユーザのアカウントの第２状態を通常状態から認証情報要変更状態に移行させ、
第２のユーザ認証が成功した場合に、第２状態が通常状態であれば、第１の変更情報を用いて第１のユーザ認証情報を変更してユーザにログインを許可し、
第２のユーザ認証が成功した場合に、第２状態が認証情報要変更状態であれば、第１の変更情報による第１のユーザ認証情報の変更は行わずに、第３のユーザ認証情報と、第２のユーザ認証情報に対応する第２の変更情報と、の入力をユーザに促し、
ユーザから入力された第３のユーザ認証情報に基づき第３のユーザ認証を実行し、
第３のユーザ認証が成功した場合に、第１の変更情報を用いて第１のユーザ認証情報を変更し、第２の変更情報を用いて第２のユーザ認証情報を変更してユーザにログインを許可し、
第３のユーザ認証が失敗した場合には、第１の変更情報による第１のユーザ認証情報の変更、及び、第２の変更情報による第２のユーザ認証情報の変更、を行わないまま、ユーザのログインを拒否する、
処理をコンピュータシステムに実行させるためのプログラム。
請求項１記載のプログラムであって、
特別ユーザを登録し、
登録された特別ユーザについて前記第１の不正アクセス条件が満足された場合には、当該ユーザのアカウントの第１状態を認証情報要変更状態とし、
特別ユーザ以外のユーザについて前記第１の不正アクセス条件が満足された場合には、当該ユーザのアカウントをロックアウト状態とする、
処理を更に前記コンピュータシステムに実行させることを特徴とするプログラム。
ユーザから入力された第１のユーザ認証情報に基づくユーザ認証において、第１の不正アクセス条件が満足された場合に、当該ユーザのアカウントの第１状態を認証情報要変更状態に移行させる手段と、
第１状態が認証情報要変更状態にあるユーザから正しい第１のユーザ認証情報が入力された場合に、第２のユーザ認証情報と、第１のユーザ認証情報に対応する第１の変更情報と、の入力をユーザに促す手段と、
ユーザから入力された第２のユーザ認証情報に基づき第２のユーザ認証を実行する手段と、
第２のユーザ認証において第２の不正アクセス条件が満足された場合に、当該ユーザのアカウントの第２状態を通常状態から認証情報要変更状態に移行させる手段と、
第２のユーザ認証が成功した場合に、第２状態が通常状態であれば、第１の変更情報を用いて第１のユーザ認証情報を変更してユーザにログインを許可する手段と、
第２のユーザ認証が成功した場合に、第２状態が認証情報要変更状態であれば、第１の変更情報による第１のユーザ認証情報の変更は行わずに、第３のユーザ認証情報と、第２のユーザ認証情報に対応する第２の変更情報と、の入力をユーザに促す手段と、
ユーザから入力された第３のユーザ認証情報に基づき第３のユーザ認証を実行する手段と、
第３のユーザ認証が成功した場合に、第１の変更情報を用いて第１のユーザ認証情報を変更し、第２の変更情報を用いて第２のユーザ認証情報を変更してユーザにログインを許可する手段と、
第３のユーザ認証が失敗した場合には、第１の変更情報による第１のユーザ認証情報の変更、及び、第２の変更情報による第２のユーザ認証情報の変更、を行わないまま、ユーザのログインを拒否する手段と、
を備えるコンピュータシステム。
請求項３記載のコンピュータシステムであって、
特別ユーザを登録する手段と、
登録された特別ユーザについて前記第１の不正アクセス条件が満足された場合には、当該ユーザのアカウントの第１状態を認証情報要変更状態とする手段と、
特別ユーザ以外のユーザについて前記第１の不正アクセス条件が満足された場合には、当該ユーザのアカウントをロックアウト状態とする手段と、
を更に備えることを特徴とするコンピュータシステム。