(57)【要約】【課題】  認証情報に対して対になる情報を用いて簡単にかつ高いセキュリティの認証が行えるようにした認証制御プログラムおよび認証装置を提供する。【解決手段】  ログイン可能な通常アカウントがロックされた状態において、当該通常アカウントのロック状態を解除し、再度通常アカウントによるログインを可能とする解除用アカウントを認証情報保持部２０７で管理する。認証画面に情報が入力されると、入力されたユーザＩＤに対するアカウントの種別をアカウント種別判定部２０４で判定し、解除用アカウントである場合、ロック状態判定部２０５でその解除用アカウントに対する通常アカウントの状態を判定する。ロック状態の場合にその解除用アカウントを認証部２０３で認証し、認証が成功することでその解除用アカウントに対する通常アカウントの認証を認証部２０３で行う。【選択図】図２
2008046867.tif 000002
【特許請求の範囲】
【請求項１】
認証試行回数が規定回数に至ることで無効となった認証情報を解除する解除用認証情報を当該認証情報に関連付けて管理する第１のステップと、
前記認証情報が無効になった場合に、該認証情報に対応して前記第１のステップで管理される解除用認証情報を有効とする第２のステップと、
前記第２のステップによって有効とした前記解除用認証情報の認証処理を行う第３のステップと、
前記第３のステップによる認証処理によって前記解除用認証情報が認証された場合、当該解除用認証情報に対応する認証情報を前記第１のステップによって管理された関連付けから判断する第４のステップと、
前記第４のステップによって前記解除用認証情報に対応すると判断された認証情報による再認証処理を行う第５のステップと
をコンピュータに実行させるための認証制御プログラム。
【請求項２】
前記第５のステップによる前記再認証処理によって前記認証情報の認証が行われた場合、当該認証情報に対する前記解除用認証情報を無効とする第６のステップと
を更に含む請求項１記載の認証制御プログラム。
【請求項３】
前記第５のステップによる前記再認証処理によって前記認証情報の認証が行われた場合に当該認証情報の認証試行回数を初期化する
ことを含む請求項１または２記載の認証制御プログラム。
【請求項４】
前記第１のステップは、
前記認証情報の登録に際し、鍵付きハッシュ演算処理を行うことによって前記解除用認証情報を生成し、前記認証情報に該解除用認証情報を関連付けて管理する
ことを含む請求項１から３のいずれかに記載の認証制御プログラム。
【請求項５】
前記第１のステップは、
無効になった解除用認証情報を解除する解除用認証情報を当該無効になった解除用認証情報に関連付けて更に管理し、
前記第３のステップによる認証試行回数が規定回数に至ることで前記解除用認証情報が無効になった場合に、該無効になった解除用認証情報に対応して前記第１のステップで管理される解除用認証情報を有効とする第６のステップと、
前記第６のステップによって有効とした解除用認証情報の認証処理を行う第７のステップと、
前記第９のステップによる再認証処理によって前記解除用認証情報が認証された場合、当該無効になった解除用認証情報に対応する解除用認証情報を前記第１のステップによって管理された関連付けから判断する第８のステップと、
前記第８のステップによって前記無効になった解除用認証情報に対応すると判断された解除用認証情報による再認証処理を行う第９のステップと
を更に含む請求項１記載の認証制御プログラム。
【請求項６】
認証試行回数が規定回数に至ることで無効となった認証情報を解除する解除用認証情報を当該認証情報に関連付けて管理する管理手段と、
前記認証情報が無効になった場合に、該認証情報に対応して前記第１のステップで管理される解除用認証情報を有効とする状態更新手段と、
前記状態更新手段によって有効とした前記解除用認証情報の認証処理を行う認証手段と、
前記認証手段による認証処理によって前記解除用認証情報が認証された場合、当該解除用認証情報に対応する認証情報を前記管理手段によって管理された関連付けから判断する判断手段と、
前記判断手段によって前記解除用認証情報に対応すると判断された認証情報による再認証処理を行う再認証手段と
を具備する認証装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ロックされた状態にあるユーザアカウントの認証制御を行う認証制御プログラムおよび認証装置に関し、特に、ロックされたユーザアカウントを簡単にかつ安全に解除し、当該ユーザアカウントによる認証を再度、行えるようにした認証制御プログラムおよび認証装置に関する。
【背景技術】
【０００２】
一般に、個人情報や取引情報などを扱うシステムでは、利用を許可したユーザのアカウントを予め登録しておき、利用時にはアカウントに対するユーザＩＤ、パスワードの認証処理を行う。すなわち、権限が付与されたユーザ若しくはその情報の本人のみをアクセス可能とし、なりすましやクラッキングなどの脅威からそれらの情報を保護している。このような脅威に対して、単なるユーザＩＤやパスワードによる認証だけでは辞書攻撃に代表される総当り攻撃によっていずれかは破られてしまうことが往々にして考えられる。
【０００３】
そのため、通常、ある一定の試行回数を超えて認証に失敗した場合にはそのアカウントを一時的に無効とするロック機能（「ロックアウト機能」ともいう）が搭載、整備されており、悪意ある第三者からの不正利用を未然に防止している。
【０００４】
しかしながら、今日の情報化社会の中で個人が利用するパスワードが複数に上ることは珍しくはなく、たとえ本人であったとしても一定の試行回数を超えて認証に失敗してしまうことがあり正規の利用者であってもロックアウト状態に陥ってしまうことが往々にして起こり得る。また、特に、機密性がとても高い情報を取り扱う場合などでは、認証の試行可能な回数が極端に低く設定されており、一回でも認証に失敗した場合には即座にロックしてしまうことがある。
【０００５】
これはセキュリティを高めるという観点からは優れた機能であるが、正規の利用者から見た場合、単なるタイプミスなどによって認証されず、利便性を大きく損ねることとなる。すなわち、正規の利用者がロック状態になってしまった場合には、簡便に解除できることが望ましい。
【０００６】
ロックされた状態に陥ったときに、ある一定の条件を満たすことで第三者の手を介することなく、そのロックされた状態を解除できるようにした技術として特許文献１に開示されたものがある。
【０００７】
この特許文献１に開示された従来技術では、ロックアウトする試行回数のロック条件と、ロックアウトされてから解除されるまでの経過時間を解除条件とを予め設定しておき、ロックアウトした場合にはその時間が経過するのを待ってロックを解除し、再度ユーザ認証を可能にしている。
【０００８】
また、特許文献２に開示された従来技術では、ロックアウト状態になったユーザＩＤに対して別の端末を用いてロックアウトを解除できるようにし、再度ユーザ認証を行うというものである。
【０００９】
この特許文献２を用いることで、第三者の手を介することなく自ら即座にロックアウト状態を解除することができるようにしている。
【特許文献１】特開２００２−２２０６０８
【特許文献２】特開２００３−１６７８４９
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、特許文献１に示された従来技術においては、予めロックアウトとなるためのロック条件やロックアウトされるまでの経過時間を指定しておく必要があるため、再度ユーザ認証を行うまでに待ち時間が生じることとなる。これは、経過時間を極端に短くした場合にはそのロックアウトがなすセキュリティ技術の意味合いが薄れることとなり、反対に経過時間を長くした場合には利便性を犠牲にすることになってしまうという問題がある。
【００１１】
また、特許文献２に示された従来技術では、ユーザ自身が別の端末を用いることで即座にロックアウト状態を解除できるように構成しているが、常に、ユーザ認証を行う装置とともにその端末を設置しなければならず、システム構成上、ユーザＩＤの認証状態を確認してロックアウト状態にあるユーザＩＤを解除するための情報を新たに管理しなければならないという問題がある。
【００１２】
そこで、本発明は、認証情報に対して対になる情報を用いて簡単にかつ高いセキュリティの認証が行えるようにした認証制御プログラムおよび認証装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、請求項１の発明は、認証試行回数が規定回数に至ることで無効となった認証情報を解除する解除用認証情報を当該認証情報に関連付けて管理する第１のステップと、前記認証情報が無効になった場合に、該認証情報に対応して前記第１のステップで管理される解除用認証情報を有効とする第２のステップと、前記第２のステップによって有効とした前記解除用認証情報の認証処理を行う第３のステップと、前記第３のステップによる認証処理によって前記解除用認証情報が認証された場合、当該解除用認証情報に対応する認証情報を前記第１のステップによって管理された関連付けから判断する第４のステップと、前記第４のステップによって前記解除用認証情報に対応すると判断された認証情報による再認証処理を行う第５のステップとを含むことを特徴とする。
【００１４】
また、請求項２の発明は、請求項１の発明において、前記第５のステップによる前記再認証処理によって前記認証情報の認証が行われた場合、当該認証情報に対する前記解除用認証情報を無効とする第６のステップとを更に含むことを特徴とする。
【００１５】
また、請求項３の発明は、請求項１または２の発明において、前記第５のステップによる前記再認証処理によって前記認証情報の認証が行われた場合に当該認証情報の認証試行回数を初期化することを特徴とする。
【００１６】
また、請求項４の発明は、請求項１乃至３のいずれかの発明において、前記第１のステップは、前記認証情報の登録に際し、鍵付きハッシュ演算処理を行うことによって前記解除用認証情報を生成し、前記認証情報に該解除用認証情報を関連付けて管理することを特徴とする。
【００１７】
また、請求項５の発明は、請求項１の発明において、前記第１のステップは、無効になった解除用認証情報を解除する解除用認証情報を当該無効になった解除用認証情報に関連付けて更に管理し、前記第３のステップによる認証試行回数が規定回数に至ることで前記解除用認証情報が無効になった場合に、該無効になった解除用認証情報に対応して前記第１のステップで管理される解除用認証情報を有効とする第６のステップと、前記第６のステップによって有効とした解除用認証情報の認証処理を行う第７のステップと、前記第９のステップによる再認証処理によって前記解除用認証情報が認証された場合、当該無効になった解除用認証情報に対応する解除用認証情報を前記第１のステップによって管理された関連付けから判断する第８のステップと、前記第８のステップによって前記無効になった解除用認証情報に対応すると判断された解除用認証情報による再認証処理を行う第９のステップとを更に含むことを特徴とする。
【００１８】
また、請求項６の発明は、認証試行回数が規定回数に至ることで無効となった認証情報を解除する解除用認証情報を当該認証情報に関連付けて管理する管理手段と、前記認証情報が無効になった場合に、該認証情報に対応して前記第１のステップで管理される解除用認証情報を有効とする状態更新手段と、前記状態更新手段によって有効とした前記解除用認証情報の認証処理を行う認証手段と、前記認証手段による認証処理によって前記解除用認証情報が認証された場合、当該解除用認証情報に対応する認証情報を前記管理手段によって管理された関連付けから判断する判断手段と、前記判断手段によって前記解除用認証情報に対応すると判断された認証情報による再認証処理を行う再認証手段とを具備することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、ユーザアカウント作成時に対となる解除用アカウントを生成し、ユーザアカウントがロック状態にある場合にのみ前記解除用アカウントによるユーザアカウントのロック解除を可能とし、解除用アカウントの認証処理後、該解除用アカウントに対するユーザアカウントの認証を行えるように構成したので、ロック状態にあるユーザアカウントをユーザ本人が簡単にかつ安全にロックを解除できるようになり利便性とともに信頼性を確保したユーザ認証を行うことが可能になるという効果を奏する。
【発明を実施するための最良の形態】
【００２０】
以下、本発明に係わる認証制御プログラムおよび認証装置の一実施例を添付図面を参照して詳細に説明する。
【実施例１】
【００２１】
図１は、本発明に係わる認証制御プログラムおよび認証装置を適用して構成した認証制御システムのネットワーク構成図の一例である。
【００２２】
図１において、認証制御システムは、複数台のクライアントＰＣ（１００−Ａ、１００−Ｂ、１００−Ｃ）（以下、総称して「クライアントＰＣ１００」という）、Ｗｅｂサーバ２００、認証サーバ３００がＬＡＮケーブルなどのネットワーク回線によって接続されている。
【００２３】
クライアントＰＣ１００には、Ｗｅｂブラウザが搭載され、ＵＲＬ（Uniform Resource Locator）を指定することでＷｅｂサーバ２００上のＷｅｂアプリケーションにアクセスする。ＵＲＬによって指定されるＷｅｂアプリケーションが配置されたＷｅｂサーバ２００では、認証サーバ３００に対してユーザＩＤ、パスワード、セキュリティコードなどの認証情報の認証要求を行い、ユーザ認証後、指定されたＵＲＬに対するＷｅｂページをＷｅｂブラウザへと応答する。
【００２４】
認証サーバ３００では、ユーザＩＤに対するパスワードやセキュリティコードなどの認証情報を管理し、Ｗｅｂブラウザから入力された認証情報と、管理した認証情報とが同一であるか比較することによってユーザ認証を行う。このときのユーザ認証に際し、誤った認証情報が入力されるなどによってユーザ認証が行えない場合には認証情報の再入力を可能とし、新たに入力された認証情報で再度ユーザ認証を行う。
【００２５】
また、認証処理の試行回数に制限を設け、一定のログイン試行回数に至っても認証できない場合には、そのユーザＩＤが示すアカウントをロックし、そのアカウントの使用を一時的に停止する。
【００２６】
さらに、認証サーバ３００では、ロックされたアカウントを解除して再度そのアカウントを用いたユーザ認証を可能とする解除用アカウントを管理する。この解除用アカウントは、ロックされたアカウント（以下、解除用アカウントと区別するため「通常アカウント」と示す）を生成する際に、鍵付きハッシュ演算などを行うことによって同時に生成され、通常アカウントと関連付けて対に管理される。
【００２７】
解除用アカウントは通常アカウントと異なるユーザＩＤのアカウントであって、解除用アカウントの認証処理はロックされた通常アカウントのロック状態を解除するために行われる処理であって、Ｗｅｂアプリケーションの利用を可能にする認証処理とは異なる。Ｗｅｂアプリケーションを利用するには解除用アカウントによって解除された通常アカウントの認証に成功する必要がある。
【００２８】
さらに、この解除用アカウントは、関連付けられた対の通常アカウントがロックされた状態にのみ有効となり、そのロック状態を解除する際に用いられるアカウントである。すなわち、認証サーバ３００では、通常アカウントのロック状態を管理するとともにその通常アカウントに関連付けられた解除用アカウントの状態をも管理する。このときの通常アカウントと解除用アカウントの管理状態の一例を図５に示す。
【００２９】
図５は、通常アカウントおよび解除用アカウントを管理したアカウント管理テーブルであって、[ユーザＩＤ]、[パスワード]からなる各アカウントには、アカウントの種類を判別する[種別]、アカウントを認証できるか否かを示す[状態]が設定される。
【００３０】
また、この[種別]に「通常」と示されている場合には、そのアカウントが通常アカウントであることを示し、[解除用アカウントユーザＩＤ]にユーザＩＤが指定されることによって、通常アカウントとその通常アカウントのロック状態を解除する解除用アカウントが相互に関連付けられる。
【００３１】
例えば、図５に示す[ユーザＩＤ]が「２００６００１５７７」、[パスワード]が「０＠３４１ｈｇ」であるアカウントには、[種別]に「通常」と設定され、[状態]に「ロック」が設定されていることからロック状態にある通常アカウントであると判別することができる。また、[解除用アカウントユーザＩＤ]に「ｋ００１２」が設定されていることから[ユーザＩＤ]が「ｋ００１２」であるアカウントが当該通常アカウントのロック状態を解除する解除用アカウントであることを示す。
【００３２】
ちなみに、この[解除用アカウントユーザＩＤ]は、通常アカウントのユーザＩＤをハッシュ演算することによって生成したハッシュ値であって、上記例の場合、[ユーザＩＤ]の「２００６００１５７７」をハッシュ演算したハッシュ値が[解除用アカウントユーザＩＤ]の「Ｋ００１２」となる。
【００３３】
なお、ハッシュ値そのものを解除用アカウントのユーザＩＤとしない場合は、このアカウント管理テーブルにハッシュ値に対するユーザＩＤのフィールドを新たに追加することでそのハッシュ値を介して間接的にアカウント同士を関連付けるように構成してもよい。
【００３４】
そして、同様に、アカウント管理テーブルの[ユーザＩＤ]が「ｋ００１２」、[パスワード]が「ｑｗｑｅｆ９８７３」であるアカウントには、[種別]に「解除」と設定され、[状態]が「有効」と設定されていることから、このアカウントは通常アカウントのロック状態を解除することが可能な解除用アカウントであると判別することができる。
【００３５】
図５に示すようなテーブル構成によって、[ユーザＩＤ]が「２００６００１５７７」、[パスワード]が「０＠３４１ｈｇ」である通常アカウントのロック状態を[ユーザＩＤ]が「ｋ００１２」、[パスワード]が「ｑｗｑｅｆ９８７３」である解除用アカウントによって解除できることを示している。
【００３６】
このときの認証サーバ３００で行う認証処理の認証モジュール構成を図２に示しており、以下にこの認証モジュールによる認証処理を説明する。
【００３７】
図２に示す認証モジュールは、制御部２０１、画面生成部２０２、認証部２０３、アカウント種別判定部２０４、ロック状態判定部２０５、対応アカウント取得部２０６、認証情報保持部２０７によって構成され、クライアントＰＣ１００のＷｅｂブラウザからＵＲＬを指定することによってＷｅｂサーバ２００上のＷＥＢアプリケーションを利用する際に、その利用権限を有するユーザであるかを認証するモジュールである。
【００３８】
この認証モジュールでは、Ｗｅｂブラウザからの要求に対してＷｅｂサーバ上のＷｅｂアプリケーションによってユーザ認証要求が行われると処理が開始され、認証要求を受けた制御部２０１が画面生成部２０２に対して認証画面（「ログイン画面」ともいう）の生成依頼を行う。この制御部２０１では、Ｗｅｂアプリケーションからの要求内容を解析し、解析結果に応じた依頼を画面生成部２０２、認証部２０３、アカウント種別判定部２０４、ロック状態判定部２０５、対応アカウント取得部２０６、認証データ保持部２０７へとそれぞれ行う。
【００３９】
そして、制御部２０１から認証画面の生成依頼を受けた画面生成部２０２では、Ｗｅｂブラウザに表示する認証画面を生成し、Ｗｅｂブラウザ上に表示する。この認証処理は、クライアントＰＣ１００のＷｅｂブラウザと認証サーバ３００とでダイレクトに行われ、その認証結果をＷｅｂサーバ２００のＷｅｂアプリケーションに返すことによってＷｅｂアプリケーションの利用を可能とする。
【００４０】
Ｗｅｂブラウザ上に表示された認証画面にユーザがユーザＩＤ、パスワード、セキュリティコードなどの認証情報を入力すると、認証情報を受信した認証サーバ３００の制御部２０１ではその認証情報の認証依頼を認証部２０３へと送信する。また同時にアカウント種別判定部２０４に対して、ユーザＩＤのアカウントに指定された種別の判定依頼を行う。
【００４１】
アカウント種別判定部２０４では、判定依頼に基づき、入力されたユーザＩＤのアカウントの種別を判定する。判定した結果、アカウントが通常アカウントであると判定された場合には、その判定結果に基づいて制御部２０１がロック状態判定部２０５にその通常アカウントがロックされた状態にあるかの判定依頼を行う。
【００４２】
ロック状態判定部２０５による状態判定の結果、通常アカウントがロックされていない場合には、認証部２０３による認証情報のユーザ認証を行う。また、ロック状態判定部２０５によって判定した結果、ロックされた状態にある場合にはその入力されたユーザＩＤに対する通常アカウントは使用できない状態にある旨を示して認証処理を終了する。すなわち、一定のログイン試行回数に至っても認証できなかった状態にあるアカウントであることを示す。そのため、認証を行っているユーザは、解除用アカウントを用いてロック状態を解除する操作を行うことになる。
【００４３】
それに対して、アカウント種別判定部２０４によるアカウント種別を判定した結果、アカウントが解除用アカウントであると判定された場合には、その判定結果に基づいて制御部２０１がロック状態判定部２０５にその解除用アカウントが有効になっているかの判定依頼を行う。解除用アカウントが無効となっている場合には、解除用アカウントに対する通常アカウントがロックされていないまたはその解除用アカウントが使用停止状態にあるなどの理由により、認証処理ができない旨を示して処理を終了する。
【００４４】
また、解除用アカウントが有効となっている場合には、制御部２０１が認証部２０３に対して解除用アカウントの認証要求を行い、要求を受けた認証部２０３が取得した解除用アカウントの認証処理を行う。認証できない場合には認証処理を終了し、解除用アカウントが認証できた場合には、続いて、制御部２０１が対応アカウント取得部２０６に当該解除用アカウントに対する通常アカウントの取得要求を行う。対応アカウント取得部２０６では解除用アカウントに対する通常アカウントを取得して、認証部２０３が当該通常アカウントの認証処理を再度行う。
【００４５】
このときの通常アカウントはロック状態にあり、この通常アカウントを認証することによって制御部２０１から認証情報保持部２０７で管理したロック状態を解除するとともに認証された解除用アカウントを無効に変更する。これにより、解除用アカウントによって通常アカウントのロック状態が解除される。
【００４６】
ちなみに、アカウント種別判定部２０４によるアカウントの種別の判定処理は、認証情報保持部２０７で保持したユーザＩＤの種別によって判断するほか、認証情報保持部２０７で当該アカウントのユーザＩＤを管理してテーブルの種類によって判断する。後者の場合、種別によってアカウントのユーザＩＤを管理する管理テーブルを分けて管理する。さらに、ロック状態判定部２０５によるアカウントがロックされた状態にあるか否かの状態判断は、同じく認証情報保持部２０７で管理されたアカウントの状態によって判断する。
【００４７】
認証部２０３では、上記した通常アカウントまたは解除用アカウントの認証処理を行う。この認証部２０３では、ユーザＩＤが示すアカウントのパスワードが認証情報保持部２０７で管理するパスワードと同一であるかを比較することによって認証する。パスワードが同一であると判定されたことによって認証し、制御部２０１を介してＷｅｂアプリケーションへとその旨を通知する。これにより、Ｗｅｂブラウザ上でＷｅｂアプリケーションによるＷｅｂページを表示できる。
【００４８】
ユーザＩＤのアカウントに対するパスワードが認証情報保持部２０７で管理したパスワードに一致しないなどの理由により認証できない場合には、ログイン試行回数を確認後、一定のログイン試行回数に満たないことを条件に認証情報の再入力を行う認証画面をＷｅｂブラウザ上に再表示する。ログイン試行回数が一定の許可回数以上になった場合にはその旨を制御部２０１に返信して、制御部２０１から認証情報保持部２０７で管理した当該アカウントをロック状態へと変更する処理を行う。
【００４９】
このようなモジュール構成によって、通常アカウントをロックすることにより解除用アカウントを有効とし、その解除用アカウントを用いた通常アカウントのロック状態を解除する処理を行うことができる。
【００５０】
図３、図４は、本願発明の認証制御プログラムによって行われる認証処理の詳細な流れを示すフローチャートの一例である。
【００５１】
図３、図４において、ＷｅｂブラウザでＵＲＬを指定してＷｅｂアプリケーションに処理要求が行われると、Ｗｅｂアプリケーションを利用する権限を有するかを確認するために認証サーバに対して認証要求を行い、認証サーバが処理要求元のユーザを認証するために認証画面を生成する（３０１）。生成した認証画面をＷｅｂブラウザ上に表示し（３０２）、ユーザ操作によってユーザＩＤ、パスワードが認証画面上で入力されると、入力されたユーザＩＤに対するアカウントの種別を特定する（３０３）。
【００５２】
そのアカウントが示す種別がＷｅｂアプリケーションを利用する際に用いるアカウントである「通常アカウント」であるか判断する（３０４）。すなわち、認証するユーザが規定回数以上、認証に失敗し、そのユーザのアカウントが無効となっている場合にそのアカウントの無効状態を解除する「解除用アカウント」でないか判断する。
【００５３】
この判断処理の判断結果に基づいて、通常アカウント認証処理または解除用アカウント認証処理のいずれかを行う。
【００５４】
まず、アカウントが通常アカウントである場合（３０４でＹＥＳ）に行われる通常アカウント認証処理では、その通常アカウントがロックされたロック状態にあるか否かの判断を行う（３０５）。判断した結果、ロック状態にある場合（３０５でＹＥＳ）には入力されたユーザＩＤに対する通常アカウントがロックされている旨のエラー画面（１）を表示する（３１３）か、単に、認証できないためログインできない旨を表示する。
【００５５】
後者の場合、アカウントがロックされていて使用できない状態にあるのか、若しくは永久的に使用が禁止されているアカウントであるかの判断が不可能となり、悪意ある第三者（攻撃者）などによってロックされた場合にセキュリティを確保することができる。
【００５６】
また、通常アカウントがロック状態にない場合（３０５でＮＯ）には、入力されたユーザＩＤおよびパスワードの認証処理を行う（３０６）。認証処理によってユーザＩＤに対する通常アカウントが認証できた場合（３０６でＹＥＳ）には、認証処理を行った回数であるログイン試行回数を初期化して（３１４）Ｗｅｂアプリケーションによるサービスの提供を開始する。
【００５７】
誤ったパスワードが入力されるなどして認証できない場合（３０６でＮＯ）には、ログイン試行回数をインクリメント（プラス１）する。そして、このインクリメント後のログイン試行回数が所定の許可回数以上であるか判断し（３０９）、ログイン試行回数が許可回数未満である場合（３０９でＮＯ）には、再度通常アカウントの認証処理を行うために認証画面を表示させて（３０２）、上記通常アカウントの認証処理を繰り返し行う。
【００５８】
それに対して、ログイン試行回数が許可回数以上となった場合（３０９でＹＥＳ）、すなわち、許可回数以上通常アカウントが認証できない場合にはその通常アカウントに対する解除用アカウントを取得する（３１０）。解除用アカウントを取得後、その通常アカウントの状態をロック状態へと変更し（３１１）、取得した解除用アカウントの状態を「有効」へと変更する（３１２）。この処理により、解除用アカウントの認証が可能になる。
【００５９】
この場合、許可回数以上認証できずにロック状態となった通常アカウントを解除するために、解除用アカウントの認証処理を行う。
【００６０】
次に、アカウントの種別の判断処理（３０４）によって入力されたユーザＩＤのアカウントが通常アカウントではなく、解除用アカウントであると判断された場合（３０４でＮＯ）に行われる解除用アカウント認証処理では、認証画面で入力されたユーザＩＤに対する解除用アカウントが「有効」になっているか判断する（３１５）。
【００６１】
有効になっていない場合（３１５でＮＯ）、すなわち、ロックされた状態にない通常アカウントに対する解除用アカウントのユーザＩＤが入力された場合には、通常アカウントがロックされていない旨を示すエラー画面（２）を表示する（３２７）。このときも単に、認証できないためログインできない旨を表示するようにしてもよい。
【００６２】
また、解除用アカウントが有効になっている場合（３１５でＹＥＳ）には、入力された解除用アカウントのユーザＩＤとパスワードを認証する（３１６）。認証できたか判断し（３１７）、認証できない場合（３１７でＮＯ）にはロック解除用のアカウントも認証できない旨のエラー画面（３）を表示して（３２８）処理を終了する。このときも単に、認証できないためログインできない旨を表示するようにしてもよい。
【００６３】
解除用アカウントのユーザＩＤとパスワードが認証できた場合（３１７でＹＥＳ）には、続いて、認証が成功した解除用アカウントに対する通常アカウントの認証を行うために認証画面を生成する（３１８）。
【００６４】
生成した認証画面にユーザがユーザＩＤおよびパスワードを入力すると、認証が成功した解除用アカウントに対する通常アカウントのユーザＩＤを取得し（３１９）、取得したユーザＩＤが入力されたユーザＩＤと同一であるかチェックする（３２０）。チェックしたユーザＩＤが同一であるか判断して（３２１）、同一であると判断された場合（３２１でＹＥＳ）には、入力された通常アカウントに対するユーザＩＤとパスワードの認証処理を行う（３２２）。そして、認証処理によって認証できたか判断し（３２３）、認証できない場合（３２３でＮＯ）またはチェックしたユーザＩＤが同一でない場合（３２１）には、通常アカウントのロックが解除できない旨のエラー画面を示す（３２９）。このときも単に、認証できないためログインできない旨を表示するようにしてもよい。
【００６５】
それに対して、通常アカウントのユーザＩＤとパスワードが認証できた場合（３２３でＹＥＳ）には、認証した通常アカウントのロックを解除した状態であるアンロック状態へと変更し（３２４）、そのときの解除用アカウントの状態を「無効」へと変更する（３２５）。そして、ログイン試行回数を初期化する（３２６）。
【００６６】
このような処理により、解除用アカウントを用いて通常アカウントのロック状態を解除することができるようになり、また、その通常アカウントによる認証が可能となる。
【実施例２】
【００６７】
以下に示す実施例２では、複数の解除用アカウントを用いた多重ロックの例を示しており、通常アカウント同様、解除用アカウントが一定の回数に至っても認証できない場合にその解除用アカウントのロックし、ロックした解除用アカウントを解除するための解除用アカウントを設ける。すなわち、解除用アカウントのロック状態を解除するためのアカウントであって、各アカウント間でネスト構造を形成する。
【００６８】
このときの各アカウント間の相関関係を図６に示す。
【００６９】
図６は、通常アカウントおよび複数の解除用アカウントから構成されるアカウント管理テーブルであって、その構成は図５に示すテーブル構成と類似するため、図５と異なる点を中心に説明する。
【００７０】
図６に示すアカウント管理テーブルは、[ユーザＩＤ]、[パスワード]によって示されるアカウントそれぞれに対して、そのアカウントの種類を示す[種別]と、各アカウントのロック状態を示した[状態１]と、各アカウントによる認証の可否を示した[状態２]が設定されている。
【００７１】
さらに、各アカウントのロック状態を解除する解除用のアカウントが設定されている場合には、[解除用アカウントユーザＩＤ]にその解除用アカウントが示すユーザＩＤが示されている。
【００７２】
例えば、[ユーザＩＤ]が「２００６００１５７９」、[パスワード]が「０２８ｙｍｌｉ」のアカウントの[種別]として「通常」が設定され、[状態１]に「ロック」が示されていることから、このアカウントは、ロック状態にある通常アカウントであると判別することができる。このアカウントには[解除用アカウントユーザＩＤ]として「７５ｊｕ８９」が指定されており、この「７５ｊｕ８９」をユーザＩＤとして持つアカウントによってロック状態を解除することができる。
【００７３】
この「７５ｊｕ８９」が[ユーザＩＤ]に設定されたアカウントには、[パスワード]に「８５ｙ４ｋｏ２」が設定されており、[種別]に「解除」と設定されていることからこのアカウントは、解除用アカウントであると判別することができる。
【００７４】
また、[状態１]が「ロック」であって[状態２]が「無効」が設定されていることから、この解除用アカウントもロック状態にあり、この解除用アカウントを用いたロック状態の解除が無効となっている。このアカウントには[解除用アカウントユーザＩＤ]として「８ｉｑ７８」が指定されており、この「８ｉｑ７８」をユーザＩＤとして持つアカウントによってロック状態を解除することができる。すなわち、解除用アカウントのロック状態を解除する解除用アカウントが設定されている状態を示している。
【００７５】
このアカウント管理テーブルには、[ユーザＩＤ]が「８ｉｑ７８」、[パスワード]が「ｐ２４ａｐｇｒａ」であるアカウントが設定されており、このアカウントの[種別]として「解除」が設定されていることから解除用アカウントであると判別することができ、[状態２]に「有効」が設定されていることから、この解除用アカウントの認証によってロック状態を解除することができる。
【００７６】
この解除用アカウントを認証することにより、この解除用アカウントの[状態２]が「有効」から「無効」へと変更され、この解除用アカウントのユーザＩＤが[解除用アカウントユーザＩＤ]に設定された[ユーザＩＤ]が「７５ｊｕ８９」、[パスワード]が「８５ｙ４ｋｏ２」によって示される解除用アカウントの[状態１]を「ロック」から「アンロック」へと変更する。
【００７７】
このようなテーブル構成によって、ネスト構造を形成したアカウントを管理でき、順次ロック状態を解除することができる。
【００７８】
続いて、通常アカウントを解除し、システムへのログインを行う処理の流れを図７のフローチャートに示す。
【００７９】
図７には、通常アカウントがロックされ、ロックされた通常アカウントを解除する解除用アカウント１の認証も失敗した場合の処理を示し、図４で示した「解除用アカウントの認証処理」（３１６）で認証に失敗したと判断された場合（３１７でＮＯ）に行われる処理フローの変形例である。すなわち、解除用アカウント１の認証が一度、失敗した状態で処理が開始される。
【００８０】
まず、解除用アカウントの階層数を「ｎ」、最大階層数を「ｍ」、ログイン試行回数を「ｋ」とし、その初期値として階層数（ｎ）を「１」、ログイン試行回数（ｋ）を「１」と設定する。また、このときの条件式として階層数（ｎ）は最大階層数（ｍ）以下である「ｎ＜＝ｍ」が成り立つ（７０１）。
【００８１】
そして、ログイン試行回数をインクリメント（（ｋ）に（ｋ＋１）を代入）し（７０２）、階層数（ｎ）に対する解除用アカウントｎのユーザＩＤおよびパスワードを入力する画面を表示してユーザにより入力された認証情報の認証処理を行う（７０２）。その認証処理によって認証できたか否かを判断し（７０３）、認証できない場合（７０３でＮＯ）には、続いて、認証処理のログイン試行回数（ｋ）が所定の許可回数以上であるか判断する（７０５）。
【００８２】
ログイン試行回数が所定の許可回数以上である場合（７０５でＹＥＳ）には、その解除用アカウントｎが認証できなかったことを示し、次の階層の解除用アカウントの認証処理に移行するために階層数（ｎ）をインクリメントする（（ｎ）に（ｎ＋１）を代入）（７０６）。インクリメント後の階層数（ｎ）が予め設定した最大階層数（ｍ）よりも大きいか判断し（７０７）、インクリメント後の階層数（ｎ）が最大階層数（ｍ）以下である場合（７０７でＮＯ）には、次階層の解除用アカウントによる認証が可能であると判断してインクリメント後の階層数（ｎ）の解除用アカウントｎを取得する（７０８）。
【００８３】
さらに、解除用アカウント「ｎ−１」（インクリメント前の解除用アカウントｎ）の状態を「ロック状態」へと変更し（７０９）、解除用アカウント（ｎ）（インクリメント後の解除用アカウント「ｎ」）の状態を「有効」へと変更して（７１０）、次階層の解除用アカウントに対するログイン試行回数（ｋ）を初期化（リセット）する（７１１）。そして、次階層の解除用アカウントの認証処理を行う。
【００８４】
次に、階層数（ｎ）に対する解除用アカウントｎの認証処理（７０３）により、認証できた場合（７０４でＹＥＳ）には、その認証した解除用アカウントの階層数が「１」であるか判断する（７１２）。解除用アカウントの階層数が「１」であるということは、通常アカウントのロック状態を解除し、その通常アカウントの認証処理を行うことができるということである。そのため、認証した解除用アカウントの階層数が「１」である場合（７１２でＹＥＳ）には、図４に示す位置（Ｃ）に戻る。
【００８５】
それに対して、階層数が「１」でない場合（７１２でＮＯ）、つまり通常アカウントが多重ロックされた状態にある場合には階層数（ｎ）をデクリメント（（ｎ）に（ｎ−１）を代入）し（７１３）、デクリメント後の解除用アカウントｎの認証を行う（７１４）。例えば、３階層の解除用アカウント３が認証された場合にはその階層数（３）を階層数（２）へとデクリメントし、２階層の解除用アカウント２の認証処理を行う。
【００８６】
デクリメント後の解除用アカウントｎを認証した結果を判断し（７１５）、認証に失敗した場合（７１５でＮＯ）には、多重ロックを解除できない旨を表示させ（７１６）処理を終了する。また、認証に成功した場合（７１５でＹＥＳ）には、その認証した解除用アカウントの階層数が「１」であるかの判断（７１２）から処理を繰り返し行う。
【００８７】
すなわち、一度解除用アカウントの認証が成功し、上位の解除用アカウントの認証処理に一度でも失敗した場合にはロックの解除処理を継続せずに、終了する。これにより、総当り攻撃などの脅威に対抗することができるようになる。
【００８８】
次に、認証のログイン試行回数が許可回数以上となって（７０５でＹＥＳ）、インクリメント後の階層数（ｎ）が最大階層数（ｍ）よりも大きくなった場合（７０７でＹＥＳ）には、認証できない旨のエラー画面を表示して（７１６）処理を終了する。
【００８９】
このような多重ロックを用いることで、より強固で安全性の高い認証処理を行うことができるようになる。
【００９０】
なお、上記実施例１および実施例２では、通常アカウントに対する認証処理が一定のログイン試行回数に至っても認証できずロック状態になった場合に、当該通常アカウントと対に設けられた解除用アカウントを認証することによってロック状態を解除し、再度通常アカウントによる認証処理を可能にしている。この方法以外にも、通常アカウントのロック状態を解除用アカウントを用いて解除するのではなく、解除用のパスワードを設け、そのパスワードの認証によってロック状態を解除してもよい。
【００９１】
すなわち、通常アカウントによるシステムへのログインにはその通常アカウントに対するユーザ名およびそのユーザ名に対するパスワードの組み合わせを認証することによって行っているが、ロック状態を解除する専用のパスワードによって解除することも可能である。この専用のパスワードは、全ての通常アカウントに対して共通的に設けられているものであるほか、通常アカウントごとにそれぞれ専用のパスワードが設けられているような構成であってもよい。
【００９２】
通常アカウントごとに設けられた専用のパスワードによってロック状態を解除するには、上記実施例１および実施例２で示したその通常アカウントと対に設けられた解除用アカウントの代わりにその専用のパスワードを設定しておく構成である。
【００９３】
さらに、通常アカウントに対して専用のパスワードが設定されている場合には、パスワードによる認証だけでなく通常アカウントに対するユーザＩＤとその専用のパスワードの組み合わせを認証するように構成しても良い。上記実施例１および実施例２では異なるアカウント、すなわち、異なるユーザＩＤによる認証処理を行っているが、専用のパスワードによってロック状態を解除する場合には同一のユーザＩＤに対して異なるパスワードとの組み合わせを認証する。
【００９４】
以上の処理によって、この実施の態様における認証制御システムでは、一定のログイン試行回数を超過してロック状態になったアカウントを当該アカウントと対に生成された解除用アカウントを用いることによって解除できる。また、システムへのログインを解除用アカウントの認証とともにロック状態になったアカウントを認証することによって行うことができる。
【００９５】
これによって、誤ってロック状態になったアカウントを高いセキュリティを確保した状態で簡単に解除することが可能になる。
【００９６】
本発明は、上記し、且つ図面に示す実施例に限定することなく、その要旨を変更しない範囲内で適宜変形して実施できるものである。
【産業上の利用可能性】
【００９７】
本発明は、ロック状態にあるユーザアカウントを用いた認証処理を行う認証制御プログラムおよび認証装置に適用可能であり、特に、規定回数以上の認証処理によって無効となったユーザアカウントを簡単にかつ安全に解除してそのユーザアカウントによる認証処理を再度行うのに有用である。
【図面の簡単な説明】
【００９８】
【図１】本発明に係わる認証制御プログラムおよび認証装置を適用して構成した認証制御システムのネットワーク構成図。
【図２】図１に示す認証サーバで行う認証処理の認証モジュールのブロック構成。
【図３】本願発明の認証制御プログラムによって行われる認証処理の詳細な流れを示すフローチャート。
【図４】本願発明の認証制御プログラムによって行われる認証処理の詳細な流れを示す他のフローチャート。
【図５】アカウントを管理したアカウント管理テーブルを示す図。
【図６】ネスト構造を形成したアカウントを管理したアカウント管理テーブルを示す図。
【図７】多重ロックにおける認証処理の流れを示すフローチャート。
【符号の説明】
【００９９】
１００      クライアントＰＣ
２００      Ｗｅｂサーバ
３００      認証サーバ
２０１      制御部
２０２      画面生成部
２０３      認証部
２０４      アカウント種別判定部
２０５      ロック状態判定部
２０６      対応アカウント取得部
２０７      認証情報保持部
【図１】
2008046867.tif 000003
【図２】
2008046867.tif 000004
【図３】
2008046867.tif 000005
【図４】
2008046867.tif 000006
【図５】
2008046867.tif 000007
【図６】
2008046867.tif 000008
【図７】
2008046867.tif 000009