認証システム、検出装置、端末および認証方法

【課題】ソフトウェアトークン取得の失敗頻度を低減可能な認証システムを得ること。
【解決手段】固定のパスワードである第１のパスワードおよび可変のパスワードである第２のパスワードから構成される認証パスワードを用いた認証処理を行う認証システムであって、所定の認証要求およびトークン取得要求を送信する端末１と、受信した認証要求に応じて認証処理を行う認証サーバ４と、受信したトークン取得要求に応じてトークンを返信するトークン取得サーバ６と、前記端末１と前記トークン取得サーバ６との間の通信を中継する検出装置８と、を備え、前記検出装置８は、前記トークン取得サーバ６から受信する当該トークン取得サーバ６の混雑状態に基づいて、前記端末から受信したトークン取得要求をトークン取得サーバへ転送するかどうかを判断する状態検出部８２、を備える。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの認証を行う認証システムに関する。
【背景技術】
【０００２】
従来、ノートＰＣや携帯電話機等の端末を用いて社外から社内のシステムに遠隔接続する場合、社内システムの認証サーバは、ユーザ認証を行って利用者の正当性を確認したうえで端末と接続する。この際、認証におけるセキュリティ性を高めるため、複数要素を組み合わせてワンタイムパスワードを生成して認証を行う方式が主流となっている。例えば、ＲＳＡＳｅｃｕｒＩＤに代表されるハードトークンを用いる方式では、ハードトークンに示された文字と固定パスワードを組み合わせてワンタイムパスワードを決定し、当該パスワードを用いて認証を行う。しかしながら、この方式では、ハードトークンを紛失した場合、社外から接続できなくなるという問題がある。また、利用者全員にハードトークンを配布するため、各ハードトークンの管理運用に関するコストが増大するという問題がある。
【０００３】
下記特許文献１には、これらの問題を解決する方法として、端末にソフトウェアトークンをインストールして、端末内に表示されるトークン値と固定パスワードとを組み合わせたワンタイムパスワードを認証サーバに与えて認証を行う認証システムの技術が開示されている。
【０００４】
具体的には、ユーザが端末にユーザＩＤを入力すると、端末は、まず、認証サーバへユーザＩＤを送信する。認証サーバは、トークンに相当するマトリクス表を生成し、暗号化して端末に返信する。端末は、暗号化されたマトリクス表を復号して表示する。端末を使用するユーザは、予めユーザが規定して認証システムに登録しておいたパターン登録ルールに基づいて、マトリクス表から数字の組み合わせをつくり、端末が、これらの数字をパスワードとして認証サーバへ送信する。認証サーバは、マトリクス表、ユーザＩＤ、パターン登録ルールからパスワードを照合して認証を行う。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２６４８３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来の認証システムでは、マトリクス表の取得や端末への返信に暗号化が伴うため、１ユーザ分のマトリクス表取得のために多くのトラヒックやＣＰＵ負荷を必要とする。そのため、ユーザ数が増大すると通常のＷｅｂシステムよりもＣＰＵ負荷が増え、マトリクス表取得失敗の発生頻度が増大しやすくなる、という問題があった。また、失敗の発生頻度が増大した場合、認証システムでは、ユーザによるリトライが増加し、マトリクス表取得失敗頻度が連鎖的に高くなると同時に、さらに、強力なＤｏＳ攻撃を受けるリスクも想定される、という問題があった。
【０００７】
本発明は、上記に鑑みてなされたものであって、ソフトウェアトークンを取得する際の失敗頻度を低減することが可能な認証システムを得ることを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、本発明は、固定のパスワードである第１のパスワードおよび可変のパスワードである第２のパスワードから構成される認証パスワードを用いた認証処理を行う認証システムであって、所定の認証要求およびトークン取得要求を送信する端末と、前記第２のパスワードを求めるための規則をユーザごとに記憶し、受信した認証要求に応じて認証処理を行う認証サーバと、受信したトークン取得要求に応じてトークンを返信するトークン取得サーバと、前記端末と前記トークン取得サーバとの間の通信を中継する検出装置と、を備え、前記検出装置は、前記トークン取得サーバから所定の周期で受信する当該トークン取得サーバの混雑状態に基づいて、前記端末から受信したトークン取得要求をトークン取得サーバへ転送するかどうかを判断する状態検出手段、を備え、前記端末は、前記トークン取得サーバから前記検出装置経由で受信したトークン、および前記規則に基づいて前記第２のパスワードを決定し、前記第１のパスワードおよび当該第２のパスワードから認証パスワードを生成し、前記所定の認証要求として、当該認証パスワードを含む認証要求を前記認証サーバへ送信する、ことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ソフトウェアトークンを取得する際の失敗頻度を低減できる、という効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、認証システムの構成例を示す図である。
【図２】図２は、状態検出部の構成例を示す図である。
【図３】図３は、管理テーブルの構成例を示す図である。
【図４】図４は、検出処理を示すフローチャートである。
【図５】図５は、パケット処理を示すフローチャートである。
【図６】図６は、出力処理を示すフローチャートである。
【図７】図７は、トークン表示部に表示される画面（混雑中）を示す図である。
【図８】図８は、トークン表示部に表示される画面（混雑解消直後）を示す図である。
【図９】図９は、トークン表示部に表示される画面（混雑していないとき）を示す図である。
【図１０】図１０は、トークン取得サーバの処理（混雑中）を示すシーケンス図である。
【図１１】図１１は、トークン取得サーバの処理（混雑解消直後および混雑していないとき）を示すシーケンス図である。
【図１２】図１２は、検出処理を示すフローチャートである。
【図１３】図１３は、認証処理を示すフローチャートである。
【図１４】図１４は、認証処理を示すフローチャートである。
【図１５】図１５は、検出処理を示すフローチャートである。
【図１６】図１６は、検出処理を示すフローチャートである。
【図１７】図１７は、パケット処理を示すフローチャートである。
【図１８】図１８は、出力処理を示すフローチャートである。
【図１９】図１９は、トークン表示部に表示される画面（ＤｏＳ攻撃を受けた可能性がある場合）を示す図である。
【図２０】図２０は、トークン表示部に表示される画面（ＤｏＳ攻撃が収束した場合）を示す図である。
【発明を実施するための形態】
【００１１】
以下に、本発明にかかる認証システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１２】
実施の形態１．
図１は、本実施の形態の認証システムの構成例を示す図である。認証システムは、ユーザが認証を行うために利用する端末１と、アクセスサーバ３と、認証サーバ４と、トークン取得サーバ６と、検出装置８と、を備え、これらがネットワーク２、５、７、９を介して接続されている。本認証システムでは、一例として、ユーザごとに固定のパスワードと、トークンから求めた時系列的に可変なパスワードと、を組み合わせることにより認証に必要なパスワードを生成する。なお、上記固定の単位としては、ユーザ単位に限定するものではない。
【００１３】
まず、本実施の形態の認証システムで前提となる各構成の認証動作について説明する。端末１は、トークン取得サーバ６へトークンを要求し、取得したトークンを表示するトークン表示部１１と、ユーザＩＤやパスワード等を入力し、認証サーバ４へ認証要求を行うアカウント入力部１２と、を備える。アクセスサーバ３は、端末がシステムに接続する際にアクセスする一般的なサーバである。
【００１４】
認証サーバ４は、端末１のアカウント入力部１２に入力したユーザＩＤと、ユーザがトークン取得サーバ６から参照し取得したトークンを用いてアカウント入力部１２に入力されたワンタイムパスワードを認証するための装置である。この認証サーバ４では、ネットワーク２、アクセスサーバ３経由で、ユーザＩＤおよびワンタイムパスワードをパスワード受信部４１で受信すると、トークン取得サーバ６のトークン生成部６２からネットワーク５を経て入手したトークンパターンと、予めユーザによりトークン認識部４２に登録されたトークン認識規則を用いて照合部４３が認証用のパターンを生成し、認証部４４においてパターンが正常であるかどうかを判定する。
【００１５】
トークン取得サーバ６は、端末１に表示するトークン値を管理するための装置であり、ユーザがトークンを取得するときは、検出装置８、ネットワーク９を介して取得する。トークン取得サーバ６は、生成したトークの送受信を行うトークン送受信部６１と、端末１からの要求（トークン取得リクエスト）に応じてトークンを生成するトークン生成部６２と、生成したトークンとユーザごとの対応付けを行うため、端末１からのトークン取得リクエスト受信時、または認証サーバ４からの要求によりトークンを送信する際に、ユーザＩＤを受信するユーザＩＤ受信部６３と、自サーバのＣＰＵ負荷等の性能を収集する性能収集部６４と、を備える。
【００１６】
検出装置８は、トークン取得サーバ６との通信が可能なセグメントに設置され、ネットワーク７を介して認証サーバ４との通信が可能である。検出装置８は、インタフェース部８１と、状態検出部８２と、状態出力部８３と、管理テーブル８４と、状況診断部８５と、を備える。
【００１７】
インタフェース部８１は、ネットワーク９からパケットを受信するたびに、パケットフィルタを起動し、端末１とトークン取得サーバ６との間を流れるトラヒックリストを収集する。収集したトラヒックリストをもとに、端末１とトークン取得サーバ６を結ぶセッション、端末１のＩＰアドレス、端末１のＩＰアドレスに関するトラヒック量、アクセス回数に関するエントリを生成し、管理テーブル８４を更新する。
【００１８】
図２は、状態検出部８２の構成例を示す図である。状態検出部８２は、端末１からトークン取得サーバ６へのリクエストを受信し、また、トークン取得サーバ６の混雑状態に応じた対応を状態出力部８３に出力するパケット処理部８２１と、トークン取得サーバ６の混雑状態を判定する検出処理部８２２と、トークン取得サーバ６からトークンを受信するトークン取得部８２３と、トークン取得サーバ６の混雑状態を管理する混雑状態記憶テーブル８２４と、トラヒックの異常状態を管理する異常検出テーブル８２５と、を備える。
【００１９】
状態出力部８３は、状態検出部８２から通知されるトークン取得サーバ６の混雑状態に関する情報を受信すると、端末１に表示させるための画面を作成し、インタフェース部８１、ネットワーク９を介して、端末１にメッセージを送信する。なお、端末１から状態検出部８２へのパケット送信、状態出力部８３から端末１へのパケット送信はＨＴＴＰをはじめとしたＴＣＰ／ＩＰ通信によって実現可能である。
【００２０】
図３は、管理テーブル８４の構成例を示す図である。管理テーブル８４は、テーブル８４１と、テーブル８４２と、から構成される。テーブル８４１は、トークン取得サーバ６で確立しているセッションと、トークン取得サーバ６と通信している相手先（端末）のＩＰアドレスおよびトラヒック量、相手先からのアクセス回数を示すものである。インタフェース部８１が、エントリを収集し、テーブル８４１に反映する。
【００２１】
テーブル８４２は、ＣＰＵ負荷の使用率、およびメモリの使用率を示すものである。検出処理部８２２が、トークン取得サーバ６の性能収集部６４からＣＰＵ負荷やメモリ使用率を予め定められた間隔で収集し、テーブル８４２に反映する。ＣＰＵ負荷やメモリ使用率の取得に関しては、状態検出部８２の検出処理部８２２が定期的にトークン取得サーバ６の性能収集部６４に対してＳＮＭＰ通信を行い、性能収集部６４からのＳＮＭＰ応答によって取得することで実現される。
【００２２】
以上の構成および動作を踏まえたうえで、本実施の形態では、検出装置８がトークン取得サーバ６の混雑状況をＣＰＵ負荷で判断し、その混雑状況に基づいてユーザに通知する内容を決定する処理について説明する。
【００２３】
図４は、検出処理部８２２の検出処理を示すフローチャートである。まず、検出処理部８２２が、性能収集部６４から、トークン取得サーバ６のＣＰＵ負荷Ｐ１を一定周期で収集する（ステップＳ１）。ＣＰＵ負荷Ｐ１が閾値Ｆ１より大きい場合（ステップＳ２：Ｙｅｓ）、トークン取得サーバ６が混雑中と判定し、混雑状態記憶テーブル８２４の混雑状態値を「有り」に更新する（ステップＳ３）。ＣＰＵ負荷Ｐ１が閾値Ｆ１以下の場合（ステップＳ２：Ｎｏ）、トークン取得サーバ６が混雑していないと判定し、混雑状態記憶テーブル８２４の混雑状態値を「無し」に更新する（ステップＳ４）。なお、混雑状態が「有り」から「無し」に、あるいは「無し」から「有り」に変化した場合は、混雑状態変化値を「有り」に変更する。
【００２４】
つぎに、パケット処理部８２１で端末１からトークン取得サーバ６へのトークン取得リクエストを受信したときのパケット処理について説明する。図５は、パケット処理部８２１のパケット処理を示すフローチャートである。パケット処理部８２１は、トークン取得リクエストを検出すると、トークン取得リクエスト中に書かれた発信ＩＰアドレスを収集する（ステップＳ１１）。そして、混雑状態記憶テーブル８２４から混雑状態値を読み出し、トークン取得サーバ６の混雑状態値を把握する（ステップＳ１２）。混雑状態記憶テーブル８２４の混雑状態値が「有り」の場合（ステップＳ１２：Ｙｅｓ）、混雑状態記憶テーブル８２４の混雑状態（混雑中）とＩＰアドレスを状態出力部８３へ通知する（ステップＳ１３）。この場合、トークン取得サーバ６へトークン取得リクエストを転送しない。一方、混雑状態値が「無し」、すなわち混雑緩和状態の場合（ステップＳ１２：Ｎｏ）、トークン取得サーバ６へトークン取得リクエストを転送し、その応答としてトークン取得サーバ６からトークンを取得する（ステップＳ１４）。そして、混雑状態値変化値が「有り」の場合（ステップＳ１５：Ｙｅｓ）、混雑状態（混雑状態緩和）、ＩＰアドレス、トークンを状態出力部８３へ通知する（ステップＳ１６）。混雑状態値変化値が「無し」の場合（ステップＳ１５：Ｎｏ）、ＩＰアドレスとトークンを状態出力部８３へ通知する（ステップＳ１７）。なお、状態出力部８３へ通知を行う場合に、状態検出部８２では、トークンと、当該トークンを取得した端末のＩＰアドレスおよびユーザＩＤの対応関係を記憶しているものとする。
【００２５】
パケット処理部８２１では、混雑状態記憶テーブル８２４の混雑状態値が「有り」の場合（ステップＳ１２：Ｙｅｓ）、混雑状態記憶テーブル８２４の混雑状態（混雑中）とＩＰアドレスを状態出力部８３へ通知する（ステップＳ１３）が、この場合、所定の周期でステップＳ１２の処理を行う。これにより、混雑状態が緩和したときに、ステップＳ１２：Ｎｏに続く処理を行うことができる。
【００２６】
状態出力部８３は、状態検出部８２のパケット処理部８２１から通知を受けると、端末１に対する出力処理を実施する。図６は、状態出力部８３の出力処理を示すフローチャートである。状態出力部８３は、パケット処理部８２１で決定された内容（ステップＳ１３、Ｓ１６、Ｓ１７）を確認する（ステップＳ２１）。
【００２７】
パケット処理部８２１がステップＳ１３の処理を行った場合（ステップＳ２１：ステップＳ１３）、図７に示す画面１１１を出力するための情報を作成する（ステップＳ２２）。図７は、トークン表示部に表示される画面１１１（混雑中）を示す図である。詳細には、ユーザに対してトークン取得サーバ６が混雑していることを示しており、これにより、リトライを控えさせるものである。
【００２８】
また、パケット処理部８２１がステップＳ１６の処理を行った場合（ステップＳ２１：ステップＳ１６）、図８に示す画面１１２を出力するための情報を作成する（ステップＳ２３）。図８は、トークン表示部に表示される画面１１２（混雑解消直後）を示す図である。詳細には、トークン取得サーバ６から取得したトークン、およびトークン取得サーバ６が混雑状態から解消した直後であるが通常使用が可能であること、をユーザに対して示すものである。
【００２９】
また、パケット処理部８２１がステップＳ１７の処理を行った場合（ステップＳ２１：ステップＳ１７）、図９に示す画面１１３を出力するための情報を作成する（ステップＳ２４）。図９は、トークン表示部に表示される画面１１３（混雑していないとき）を示す図である。詳細には、ユーザに対してトークン取得サーバ６から取得したトークンを示しており、これにより、トークン取得サーバ６が混雑していない状態であることを知らせるものである。
【００３０】
出力画面の情報を作成後、状態出力部８３は、通知されたＩＰアドレス宛の端末１に対してレスポンスを送信する（ステップＳ２５）。端末１は、状態出力部８３からレスポンスを受信すると、画面１１１、１１２、１１３のいずれかをトークン表示部１１に表示する。
【００３１】
上記各構成による処理をシーケンス図に基づいて説明する。図１０は、トークン取得サーバ６が混雑している場合の処理を示すシーケンス図である。端末１がトークン取得リクエストを送信すると（ステップＳ３１）、これを受信した状態検出部８２が、図４、５に示すフローチャートの処理に基づいてトークン取得サーバ６が混雑状態であると判断したため、その旨を示す混雑状態値を状態出力部８３へ通知する（ステップＳ３２）。状態出力部８３は、トークン取得サーバ６が混雑状態であることを示す画面１１１を作成して端末１へ送信する（ステップＳ３３）。端末１は、トークン表示部１１に画面１１１を表示する。
【００３２】
図１１は、トークン取得サーバ６が混雑解消直後または混雑していない場合の処理を示すシーケンス図である。端末１がトークン取得リクエストを送信すると（ステップＳ４１）、これを受信した状態検出部８２が、図４、５に示すフローチャートの処理に基づいてトークン取得サーバ６が混雑状態ではないと判断したため、トークン取得リクエストをトークン取得サーバ６へ送信する（ステップＳ４２）。トークン取得サーバ６は、トークン取得リクエストの応答として、状態検出部８２へトークンを送信する（ステップＳ４３）。そして、状態検出部８２は、取得したトークンおよびトークン取得サーバ６の混雑状態値を状態出力部８３へ出力する（ステップＳ４４）。状態出力部８３は、トークン取得サーバ６の混雑状態値に応じた画面（１１２または１１３）を作成し、トークンとともに端末１へ送信する（ステップＳ４５）。端末１は、トークン表示部１１に、混雑が緩和したときには画面１１２を、混雑していないときには画面１１３を表示する。
【００３３】
端末１を使用中のユーザは、これらの表示を得ることでトークン取得サーバ６の混雑状況を認識することが可能となる。そのため、トークン取得サーバ６が混雑中にはユーザに対してリトライを控えさせることができるため、混雑中のリトライ要求が削減され、リトライに伴う余剰トラヒックを削減することができる。また、他のユーザが同時にトークンを利用できなくなる状態を防ぐ効果を得ることができる。
【００３４】
以上説明したように、本実施の形態では、ユーザがトークンの取得を要求する場合に、検出装置８が、トークン取得サーバ６のＣＰＵ負荷に基づいて混雑状態を確認し、混雑していると判断した場合には、トークン取得サーバ６へトークン取得リクエストを転送せず、端末１（ユーザ）に対して、リトライをしない旨の表示を行い、一方、混雑していないと判断した場合には、トークン取得サーバ６へトークン取得リクエストを転送してトークンの取得処理を行い、取得したトークンを端末１へ転送することとした。これにより、混雑状態のときには、端末１からのリトライ要求が削減されることにより余剰トラヒックが削減され、システム内において、他のユーザがソフトウェアトークンを取得する際の失敗の頻度を低減することができる。
【００３５】
実施の形態２．
本実施の形態では、検出装置８が、トークン取得サーバ６の混雑状況を、トークン取得サーバ６で確立されているセッション数を用いて判断する。実施の形態１と異なる部分について説明する。
【００３６】
セッション数によって混雑状況を判断する場合、検出装置８の検出処理部８２２は、図１２に示す検出処理を実施することで実現することができる。図１２は、検出処理部８２２の検出処理を示すフローチャートである。まず、検出処理部８２２が、図３に示すテーブル８４１を用いて、端末１とトークン取得サーバ６との間で確立されている総セッション数Ｐ２を収集する（ステップＳ５１）。収集したセッション数Ｐ２が予め定められた閾値Ｆ２より大きい場合（ステップＳ５２：Ｙｅｓ）、トークン取得サーバ６が混雑中と判定し、混雑状態記憶テーブル８２４の混雑状態値を「有り」に変更する（ステップＳ５３）。総セッション数Ｐ２が閾値Ｆ２以下の場合（ステップＳ５２：Ｎｏ）、トークン取得サーバ６が混雑していないと判定し、混雑状態記憶テーブル８２４の混雑状態値を「無し」に変更する（ステップＳ５４）。なお、混雑状態が「有り」から「無し」に、あるいは「無し」から「有り」に変化した場合は、混雑状態変化値を「有り」に変更する。
【００３７】
以降、パケット処理部８２１、状態出力部８３、および端末１の処理については実施の形態１と同様である。トークン取得サーバ６が混雑状態の場合には、図１０に示す処理を経て、端末１が画面１１１（図７参照）を表示する。一方、トークン取得サーバ６が混雑していない場合には、図１１に示す処理を経て、端末１が画面１１２（図８参照）または画面１１３（図９参照）を表示する。
【００３８】
以上説明したように、本実施の形態では、ユーザがトークンの取得を要求する場合に、検出装置８が、トークン取得サーバ６で確立されているセッション数に基づいて混雑状態を確認することとした。これにより、実施の形態１と同様の効果を得ることができる。
【００３９】
実施の形態３．
本実施の形態では、端末１に対する混雑状態の通知を認証サーバ４が実施する。実施の形態１、２と異なる部分について説明する。
【００４０】
認証システムでは、検出装置８の状況診断部８５が、管理テーブル８４の内容が読み出し可能であり、また、トークン取得サーバ６の状態に関して認証サーバ４と通信を行う。状況診断部８５は、ネットワーク７を介して認証サーバ４と接続する。
【００４１】
認証サーバ４は、パスワード受信部４１において端末１からユーザＩＤとワンタイムパスワードを受信すると、照合部４３が、予めユーザによりトークン認識部４２に登録されたトークン認識規則、および、ネットワーク５を経由してトークン取得サーバ６から入手したトークンを用いてワンタイムパスワードを照合し、認証部４４において認証を行う。認証部４４は、トークン取得サーバ６の混雑状態を踏まえて、認証処理を実施するかどうかを決定する。
【００４２】
つづいて、認証部４４の認証処理について説明する。図１３は認証部４４の認証処理を示すフローチャートである。認証部４４は、まず、照合部４３からアカウントを入力すると（ステップＳ６１）、状況診断部８５に対してトークン取得サーバ６の混雑状態を問い合わせる（ステップＳ６２）。状況診断部８５は、認証部４４から問い合わせを受けると、混雑状態記憶テーブル８２４の混雑状態値を読み出し、その結果を認証部４４に応答する。認証部４４は、状況診断部８５からの応答内容を確認し、混雑状態（混雑状態値が「有り」）の場合（ステップＳ６３：Ｙｅｓ）、認証ＮＧ応答とサーバ混雑を示す理由を認証応答パケットに入力し、アクセスサーバ３経由で端末１に応答する（ステップＳ６４）。一方、混雑状態でない（混雑状態値が「無し」）場合（ステップＳ６３：Ｎｏ）、パスワードの正当性を判断する処理を行い、パスワードの正当性に従って認証応答を返す（ステップＳ６５）。
【００４３】
ソフトウェアトークンを用いた認証をリモートアクセスサービスに適用する場合、アプリケーション同士の連携を容易にするためにトークンを表示する画面と認証画面が異なることがある。このような場合に、認証サーバ４が上記処理を行うことにより、ユーザは認証画面を通じてトークン取得サーバ６の混雑状態を素早く認識することが可能となる。
【００４４】
以上説明したように、本実施の形態では、認証サーバ４が、ユーザに対してトークン取得サーバ６の混雑状態を通知することとした。これにより、実施の形態１、２と同様の効果を得ることができる。
【００４５】
実施の形態４．
本実施の形態では、認証サーバ４の認証部４４が行う認証処理において、端末１のＩＰアドレス情報を加味する。実施の形態３と異なる部分について説明する。
【００４６】
例えば、端末１では、既存の認証システムとの連携を優先するため、トークン表示部１１とアカウント入力部１２が別々のソフトウェアで提供されることがある。この場合、ある端末のトークン表示部１１にトークンを表示させ、異なる端末のアカウント入力部１２から認証に必要な情報を入力すると、認証サーバ４では、トークンを取得した端末と認証を要求する端末が異なっていても認証処理を行う、というセキュリティ上の問題がある。そのため、本実施の形態では、トークンを取得した端末と認証要求を行った端末が同一の端末の場合に限り認証処理を行う。
【００４７】
認証サーバ４が、パスワード受信部４１で端末１からのユーザＩＤとワンタイムパスワードを受信し、照合部４３で照合するまでの処理については実施の形態３と同様である。図１４は、認証部４４の認証処理を示すフローチャートである。認証部４４は、まず、照合部４３からアカウントを入力し（ステップＳ７１）、認証リクエストを要求した端末１のＩＰアドレスＹを入手する（ステップＳ７２）。つぎに、認証部４４は、ユーザＩＤを検出装置８の状況診断部８５へ転送し、問い合わせを行う。状況診断部８５は、認証部４４からユーザＩＤを受信すると、端末へトークンを送信した際に記憶しているトークン、当該端末のユーザＩＤ、およびＩＰアドレスの対応関係に基づいて、当該ユーザＩＤに関するトークンを取得した端末１のＩＰアドレスＸを入手する。状況診断部８５は、問い合わせに対する応答として、入手したＩＰアドレスＸを認証部４４へ送信する。
【００４８】
認証部４４は、状況診断部８５からの応答を受け（ステップＳ７３）、ＩＰアドレスＹとＩＰアドレスＸが同一かどうかを確認する（ステップＳ７４）。同一ではない場合（ステップＳ７４：Ｎｏ）、トークンを取得した端末と認証要求した端末が異なる端末であるとして、認証ＮＧ応答と不正アクセスを示す理由（エラーメッセージ）を認証応答パケットに入力し、アクセスサーバ３経由で端末１に応答する（ステップＳ７５）。同一の場合（ステップＳ７４：Ｙｅｓ）、トークンを取得した端末と認証要求した端末が同一の端末であるとして、パスワードの正当性を判断する処理を行い、パスワードの正当性に従って認証応答を返す（ステップＳ７６）。
【００４９】
以上説明したように、本実施の形態では、トークンを取得した端末と認証を要求した端末が同一の場合に、認証処理を行うこととした。これにより、実施の形態３の効果とともに、さらに、認証システムのセキュリティをより向上させることができる。
【００５０】
実施の形態５．
本実施の形態では、検出装置８が、トークン取得サーバ６宛のトラヒック量に基づいて異常状態を検出する。実施の形態１と異なる部分について説明する。
【００５１】
検出装置８では、管理テーブル８４のテーブル８４１（図３参照）からトラヒック量を検出し特定することができる。図１５は、検出処理部８２２の検出処理を示すフローチャートである。検出処理部８２２は、管理テーブル８４のテーブル８４１における各セッションのトラヒック量Ｔを収集し、その中で最も多いトラヒック量Ｔ１と、発信元の端末のＩＰアドレスＣを特定する（ステップＳ８１）。特定したトラヒック量Ｔ１が予め設定された閾値Ｇ１より大きい場合（ステップＳ８２：Ｙｅｓ）、異常検出テーブル８２５の異常状態値を「有り」に変更する（ステップＳ８３）。また、取得した発信元の端末のＩＰアドレスＣを異常検出テーブル８２５に記憶する（ステップＳ８４）。一方、特定したトラヒック量Ｔ１が予め設定された閾値Ｇ１以下の場合（ステップＳ８２：Ｎｏ）は処理を終了する。
【００５２】
検出処理部８２２が異常を検出した場合（ステップＳ８２：Ｙｅｓ）、以降、図１６のフローチャートに基づいて処理を行う。まず、図１５のステップＳ８１で検出したＩＰアドレスＣの端末のトラヒック量Ｑを算出する（ステップＳ９１）。算出したトラヒック量Ｑが閾値Ｇ２より小さい場合（ステップＳ９２：Ｙｅｓ）、つぎに示す処理を行う。
【００５３】
ＤｏＳ攻撃のトラヒックが一旦小康状態になる可能性もあることから、閾値Ｇ２は閾値Ｇ１よりも小さな値とし、トラヒック量が閾値Ｇ２より小さくなった場合（ステップＳ９２：Ｙｅｓ）、回数Ｈをインクリメントする（ステップＳ９３）。ただし、再度閾値Ｇ１を上回るトラヒック量を検出した場合は、回数Ｈをゼロにリセットする。そして、回数Ｈが所定の回数Ｊに到達した場合（ステップＳ９４：Ｙｅｓ）、すなわち、所定の期間、トラヒック量が閾値Ｇ２より小さかった場合、異常検出テーブル８２５の異常状態変化値を「有り」に更新し、異常検出テーブル８２５の異常状態値を「無し」に更新する（ステップＳ９５）。なお、算出したトラヒック量Ｑが閾値Ｇ２以上の場合（ステップＳ９２：Ｎｏ）、および回数Ｈが所定の回数Ｊに到達しない場合（ステップＳ９４：Ｎｏ）は処理を終了する。検出処理部８２２は、所定の周期で、図１６に示す処理を繰り返し行う。
【００５４】
つぎに、パケット処理部８２１のパケット処理について説明する。図１７は、パケット処理部８２１のパケット処理を示すフローチャートである。まず、パケット処理部８２１は、端末１からトークン取得リクエストを受信すると（ステップＳ１０１）、異常検出テーブル８２５の異常状態値を確認する（ステップＳ１０２）。異常状態値が「有り」の場合（ステップＳ１０２：Ｙｅｓ）、さらに、トークン取得リクエストのＩＰアドレスが図１５のステップＳ８１の処理で検出したＩＰアドレスＣと一致するかどうかを確認する（ステップＳ１０３）。一致した場合（ステップＳ１０３：Ｙｅｓ）、このトークン取得リクエストを送信してきた端末からのトラヒックを遮断する（ステップＳ１０４）。一致しなかった場合（ステップＳ１０３：Ｎｏ）、異常状態値およびＩＰアドレスを状態出力部８３へ通知する（ステップＳ１０５）。なお、異常状態値が「有り」の場合は、トークン取得サーバ６へトークン取得リクエストを転送しない。
【００５５】
一方、異常状態値が「無し」の場合（ステップＳ１０２：Ｎｏ）、パケット処理部８２１は、さらに、異常検出テーブル８２５の異常状態変化値を確認し（ステップＳ１０６）、異常状態変化値が「有り」の場合（ステップＳ１０６：Ｙｅｓ）、ＤｏＳ攻撃によって解読パターンが解析されている可能性があることから、異常状態値およびＩＰアドレスを状態出力部８３へ通知する（ステップＳ１０７）。この場合、トークン取得サーバ６へトークン取得リクエストを転送しない。なお、一定時間経過後、異常なトラヒックの検出がなければ、異常状態変化値は「無し」に更新する。異常状態変化値が「無し」の場合（ステップＳ１０６：Ｎｏ）、トークン取得サーバ６へトークン取得リクエストを転送し、その応答としてトークン取得サーバ６からトークンを取得し（ステップＳ１０８）、ＩＰアドレスおよびトークンを状態出力部８３へ通知する（ステップＳ１０９）。
【００５６】
なお、実施の形態１の場合と同様に、異常状態値が「有り」の場合（ステップＳ１０２：Ｙｅｓ）には、所定の周期でステップＳ１０２の処理を行う。これにより、異常状態解消時に、ステップＳ１０２：Ｎｏに続く処理を行うことができる。
【００５７】
状態出力部８３は、状態検出部８２のパケット処理部８２１から通知を受けると、端末１に対する出力処理を実施する。図１８は、状態出力部８３の出力処理を示すフローチャートである。状態出力部８３は、パケット処理部８２１で決定された内容（ステップＳ１０５、Ｓ１０７、Ｓ１０９）を確認する（ステップＳ１１１）。
【００５８】
異常状態を検出した場合（ステップＳ１１１：ステップＳ１０５）、図１９に示す画面１１４を出力するための情報を作成する（ステップＳ１１２）。図１９は、トークン表示部に表示される画面１１４（ＤｏＳ攻撃を受けた可能性がある場合）を示す図である。ユーザに対して、ＤｏＳ攻撃を受けた可能性があることを示すものである。この場合、画面１１４の情報を端末１に送信することで、端末１が登録したパターンの変更を促し、状況診断部８５を経て認証サーバ４のトークン認識部４２に対して、パターン初期化を行うメッセージを通知する。認証サーバ４は、この通知を受けて、登録されているパターン登録ルールを初期化する。初期化後は、端末１からの新たなパターンが登録されるのを待つ。
【００５９】
また、異常状態から回復して間もない場合（ステップＳ１１１：ステップＳ１０７）、図２０に示す画面１１５を出力するための情報を作成する（ステップＳ１１３）。図２０は、トークン表示部に表示される画面１１５（ＤｏＳ攻撃が収束した場合）を示す図である。ユーザに対して、ＤｏＳ攻撃が収束したことを示すものである。この場合も、画面１１５の情報を端末１に送信することで、端末１が登録したパターンの変更を促し、状況診断部８５を経て認証サーバ４のトークン認識部４２に対して、パターン初期化を行うメッセージを通知する。
【００６０】
また、特に異常なトラヒックを検出しなかった場合（ステップＳ１１１：ステップＳ１０９）、実施の形態１と同様に、図９に示す画面１１３を出力するための情報を作成する（ステップＳ１１４）。
【００６１】
出力画面の情報を作成後、状態出力部８３は、通知されたＩＰアドレス宛の端末１に対してレスポンスを送信する（ステップＳ１１５）。端末１は、状態出力部８３からレスポンスを受信すると、画面１１４、１１５、１１３のいずれかをトークン表示部１１に表示する。
【００６２】
このように、特に、トークン取得サーバ６がインターネットに接続されている場合に、ＤｏＳ攻撃を防ぎ、また、ＤｏＳ攻撃を受けた可能性をユーザに通知することができる。
【００６３】
以上説明したように、本実施の形態では、状態検出部８２が、トークン取得サーバ６宛のトラヒック量に基づいて異常状態を検出し、トークン取得サーバ６がインターネットに接続されている場合に、ＤｏＳ攻撃を防いでトークンの安全性を確保できることとした。これにより、実施の形態１の効果とともに、さらに、認証システムのセキュリティをより向上させることができる。
【００６４】
なお、各実施の形態の処理を相互に組み合わせることが可能である。例えば、実施の形態５の場合において、認証サーバ４が、実施の形態３、４の認証処理を行うことが可能である。
【産業上の利用可能性】
【００６５】
以上のように、本発明にかかる認証システムは、ユーザ認証に有用であり、特に、ソフトウェアトークンを組み合わせたパスワードを用いる認証に適している。
【符号の説明】
【００６６】
１端末
２、５、７、９ネットワーク
３アクセスサーバ
４認証サーバ
６トークン取得サーバ
８検出装置
１１トークン表示部
１２アカウント入力部
４１パスワード受信部
４２トークン認識部
４３照合部
４４認証部
６１トークン送受信部
６２トークン生成部
６３ユーザＩＤ受信部
６４性能収集部
８１インタフェース部
８２状態検出部
８３状態出力部
８４管理テーブル
８５状況診断部
８２１パケット処理部
８２２検出処理部
８２３トークン取得部
８２４混雑状態記憶テーブル
８２５異常検出テーブル

【特許請求の範囲】
【請求項１】
固定のパスワードである第１のパスワードおよび可変のパスワードである第２のパスワードから構成される認証パスワードを用いた認証処理を行う認証システムであって、
所定の認証要求およびトークン取得要求を送信する端末と、
前記第２のパスワードを求めるための規則をユーザごとに記憶し、受信した認証要求に応じて認証処理を行う認証サーバと、
受信したトークン取得要求に応じてトークンを返信するトークン取得サーバと、
前記端末と前記トークン取得サーバとの間の通信を中継する検出装置と、
を備え、
前記検出装置は、
前記トークン取得サーバから所定の周期で受信する当該トークン取得サーバの混雑状態に基づいて、前記端末から受信したトークン取得要求をトークン取得サーバへ転送するかどうかを判断する状態検出手段、
を備え、
前記端末は、
前記トークン取得サーバから前記検出装置経由で受信したトークン、および前記規則に基づいて前記第２のパスワードを決定し、前記第１のパスワードおよび当該第２のパスワードから認証パスワードを生成し、前記所定の認証要求として、当該認証パスワードを含む認証要求を前記認証サーバへ送信する、
ことを特徴とする認証システム。
【請求項２】
前記検出装置は、さらに、
前記トークン取得サーバの混雑状態を記憶するための管理テーブル、
を備え、
前記状態検出手段では、
前記端末からトークン取得要求を受信した場合に前記管理テーブルに記憶されたトークン取得サーバの混雑状態を確認し、混雑状態を表す値が所定の閾値よりも大きい場合には、前記トークン取得サーバへトークン取得要求を転送しないと判断しかつ混雑している旨の情報を前記端末へ送信するための処理を行い、一方、混雑状態を表す値が所定の閾値以下の場合には、前記トークン取得サーバへトークン取得要求を転送すると判断し、かつ、トークン取得要求を当該トークン取得サーバへ転送するための処理およびその応答として当該トークン取得サーバから受信したトークンを前記端末へ転送するための処理を行う、
ことを特徴とする請求項１に記載の認証システム。
【請求項３】
前記端末は、前記検出装置から混雑している旨の情報を受信した場合、その内容を、トークン取得要求を送信した後の画面に表示する、
ことを特徴とする請求項２に記載の認証システム。
【請求項４】
前記管理テーブルに、さらに、最新の混雑状態が前回受信した混雑状態と比較して変化したかどうかを示す状態変化情報を記憶している場合、
前記状態検出手段は、前記トークン取得サーバの混雑状態を表す値が前記所定の閾値以下であればさらに前記状態変化情報を確認し、確認の結果、変化有りのときは、前記トークンとともに混雑状態が緩和した直後である旨を示す情報を送信するための処理を行う、
ことを特徴とする請求項２または３に記載の認証システム。
【請求項５】
前記検出装置は、さらに、
前記認証サーバからの要求に応じて前記管理テーブルを検索し、取得した情報を前記認証サーバへ返信する状況診断手段、
を備え、
前記認証サーバは、
前記端末から認証要求を受信した場合、前記状況診断手段に対して前記トークン取得サーバの混雑状態の取得要求を送信し、その応答として当該混雑状態を受信し、当該トークン取得サーバの混雑状態を表す値が前記所定の閾値よりも大きい場合には、認証しないことを示す情報とともに混雑している旨の情報を前記端末へ送信する、
ことを特徴とする請求項２、３または４に記載の認証システム。
【請求項６】
前記端末は、前記認証しないことを示す情報および前記混雑している旨の情報を受信した場合、その内容を、認証要求を送信した後の画面に表示する、
ことを特徴とする請求項５に記載の認証システム。
【請求項７】
前記管理テーブルに、さらに、前記トークン取得サーバからトークンを受信した端末のＩＰアドレスを記憶している場合、
前記認証サーバは、
前記端末から認証要求を受信した場合に、前記状況診断手段に対して、当該端末が受信したトークンと同一のトークンを受信している端末のＩＰアドレスを要求し、その応答として受信したＩＰアドレスと前記認証要求を送信した端末のＩＰアドレスとを比較し、比較の結果、ＩＰアドレスが異なる場合には、エラーメッセージを、前記認証要求を送信した端末へ送信する、
ことを特徴とする請求項５または６に記載の認証システム。
【請求項８】
前記管理テーブルに、さらに、前記トークン取得サーバが確立しているセッションごとのトラヒック量および当該トラヒックの送信元端末のＩＰアドレスと、異常状態の端末のＩＰアドレスとを記憶している場合、
前記状態検出手段は、
最大のトラヒック量が第１の閾値よりも大きいときに当該トラヒックの送信元端末が異常状態であるとして記憶し、その後、所定の期間にわたって当該端末からのトラヒック量が第２の閾値（第１の閾値＞第２の閾値）よりも小さくなったときに当該異常状態を解除する動作を行う場合において、
所定の端末からトークン取得要求を受信し、かつ異常状態の端末が記録された状態で、当該所定の端末と当該異常状態の端末とが同一の場合には、当該所定の端末のトラヒックを遮断するための処理を行い、
一方、所定の端末からトークン取得要求を受信し、かつ異常状態の端末が記録された状態で、当該所定の端末と当該異常状態の端末とが異なる場合には、異常状態である旨の情報を当該所定の端末へ返信するための処理を行い、
さらに、所定の端末からトークン取得要求を受信し、かつ過去に異常状態であったことを示す記録があった場合には、その旨の情報を当該所定の端末へ返信するための処理を行い、
前記状況診断手段は、前記状態検出手段により異常状態である旨の情報または過去に異常状態であったことを示す旨の情報を送信するための処理が行われた場合、前記認証サーバに対して前記規則を初期化するための情報を送信し、
前記規則を初期化するための情報を受信した認証サーバが、前記規則を初期化し、その旨の情報を前記トークン取得要求送信元の端末に対して送信する、
ことを特徴とする請求項５、６または７に記載の認証システム。
【請求項９】
前記状態検出手段は、前記混雑状態を前記トークン取得サーバのＣＰＵ負荷に基づいて判断する、
ことを特徴とする請求項１〜８のいずれか１つに記載の認証システム。
【請求項１０】
前記状態検出手段は、前記混雑状態を前記トークン取得サーバが確立しているセッション数に基づいて判断する、
ことを特徴とする請求項１〜８のいずれか１つに記載の認証システム。
【請求項１１】
所定の認証要求およびトークン取得要求を送信する端末と、受信した認証要求に応じて固定のパスワードである第１のパスワードおよび可変のパスワードである第２のパスワードから構成される認証パスワードを用いた認証処理を行いかつ当該第２のパスワードを求めるための規則をユーザごとに記憶する認証サーバと、受信したトークン取得要求に応じてトークンを返信するトークン取得サーバと、前記端末と前記トークン取得サーバとの間の通信を中継する検出装置と、を備える認証システムにおける前記検出装置であって、
前記トークン取得サーバから所定の周期で受信する当該トークン取得サーバの混雑状態に基づいて、前記端末から受信したトークン取得要求をトークン取得サーバへ転送するかどうかを判断する状態検出手段、
を備えることを特徴とする検出装置。
【請求項１２】
さらに、
前記トークン取得サーバの混雑状態を記憶するための管理テーブル、
を備え、
前記状態検出手段では、
前記端末からトークン取得要求を受信した場合に前記管理テーブルに記憶されたトークン取得サーバの混雑状態を確認し、混雑状態を表す値が所定の閾値よりも大きい場合には、前記トークン取得サーバへトークン取得要求を転送しないと判断しかつ混雑している旨の情報を前記端末へ送信するための処理を行い、一方、混雑状態を表す値が所定の閾値以下の場合には、前記トークン取得サーバへトークン取得要求を転送すると判断し、かつ、トークン取得要求を当該トークン取得サーバへ転送するための処理およびその応答として当該トークン取得サーバから受信したトークンを前記端末へ転送するための処理を行う、
ことを特徴とする請求項１１に記載の検出装置。
【請求項１３】
前記管理テーブルに、さらに、最新の混雑状態が前回受信した混雑状態と比較して変化したかどうかを示す状態変化情報を記憶している場合、
前記状態検出手段は、前記トークン取得サーバの混雑状態を表す値が前記所定の閾値以下であればさらに前記状態変化情報を確認し、確認の結果、変化有りのときは、前記トークンとともに混雑状態が緩和した直後である旨を示す情報を送信するための処理を行う、
ことを特徴とする請求項１２に記載の検出装置。
【請求項１４】
さらに、
前記認証サーバからの要求に応じて前記管理テーブルを検索し、取得した情報を前記認証サーバへ返信する状況診断手段、
を備えることを特徴とする請求項１２または１３に記載の検出装置。
【請求項１５】
前記管理テーブルに、さらに、前記トークン取得サーバからトークンを受信した端末のＩＰアドレスを記憶している場合、
前記状況診断手段は、前記認証サーバからの要求に応じて、当該認証サーバに対して認証要求を送信した端末が受信したトークンと同一のトークンを受信している端末のＩＰアドレスを返信する、
ことを特徴とする請求項１４に記載の検出装置。
【請求項１６】
前記管理テーブルに、さらに、前記トークン取得サーバが確立しているセッションごとのトラヒック量および当該トラヒックの送信元端末のＩＰアドレスと、異常状態の端末のＩＰアドレスとを記憶している場合、
前記状態検出手段は、
最大のトラヒック量が第１の閾値よりも大きいときに当該トラヒックの送信元端末が異常状態であるとして記憶し、その後、所定の期間にわたって当該端末からのトラヒック量が第２の閾値（第１の閾値＞第２の閾値）よりも小さくなったときに当該異常状態を解除する動作を行う場合において、
所定の端末からトークン取得要求を受信し、かつ異常状態の端末が記録された状態で、当該所定の端末と当該異常状態の端末とが同一の場合には、当該所定の端末のトラヒックを遮断するための処理を行い、
一方、所定の端末からトークン取得要求を受信し、かつ異常状態の端末が記録された状態で、当該所定の端末と当該異常状態の端末とが異なる場合には、異常状態である旨の情報を当該所定の端末へ返信するための処理を行い、
さらに、所定の端末からトークン取得要求を受信し、かつ過去に異常状態であったことを示す記録があった場合には、その旨の情報を当該所定の端末に返信するための処理を行い、
前記状況診断手段は、前記状態検出手段により異常状態である旨の情報または過去に異常状態であったことを示す旨の情報を送信するための処理が行われた場合、前記認証サーバに対して前記規則を初期化するための情報を送信する、
ことを特徴とする請求項１４または１５に記載の検出装置。
【請求項１７】
前記状態検出手段は、前記混雑状態を前記トークン取得サーバのＣＰＵ負荷に基づいて判断する、
ことを特徴とする請求項１１〜１６のいずれか１つに記載の検出装置。
【請求項１８】
前記状態検出手段は、前記混雑状態を前記トークン取得サーバが確立しているセッション数に基づいて判断する、
ことを特徴とする請求項１１〜１６のいずれか１つに記載の検出装置。
【請求項１９】
所定の認証要求およびトークン取得要求を送信する端末と、受信した認証要求に応じて固定のパスワードである第１のパスワードおよび可変のパスワードである第２のパスワードから構成される認証パスワードを用いた認証処理を行いかつ当該第２のパスワードを求めるための規則をユーザごとに記憶する認証サーバと、受信したトークン取得要求に応じてトークンを返信するトークン取得サーバと、前記端末と前記トークン取得サーバとの間の通信を中継する検出装置と、を備える認証システムにおける前記端末であって、
前記検出装置が、前記トークン取得サーバから所定の周期で受信する当該トークン取得サーバの混雑状態に基づいて、前記端末から受信したトークン取得要求をトークン取得サーバへ転送すると判断し、転送したトークン取得要求に対する応答として前記トークン取得サーバから受信したトークンを前記端末へ転送する場合に、
前記トークン取得サーバから前記検出装置経由で受信したトークン、および前記規則に基づいて前記第２のパスワードを決定し、前記第１のパスワードおよび当該第２のパスワードから認証パスワードを生成し、前記所定の認証要求として、当該認証パスワードを含む認証要求を前記認証サーバへ送信する、
ことを特徴とする端末。
【請求項２０】
前記検出装置が、トークン取得要求を受信した場合に管理テーブルに記憶されたトークン取得サーバの混雑状態を確認し、さらに、当該混雑状態を表す値が所定の閾値よりも大きいときに前記トークン取得サーバへトークン取得要求を転送しないと判断しかつ混雑している旨の情報を送信する場合に、
前記検出装置から受信した混雑している旨の情報を、トークン取得要求を送信した後の画面に表示する、
ことを特徴とする請求項１９に記載の端末。
【請求項２１】
前記認証サーバが、認証要求を受信した場合に前記検出装置の管理テーブルに記憶されたトークン取得サーバの混雑状態を確認し、さらに、当該混雑状態を表す値が前記所定の閾値よりも大きいときに認証しないことを示す情報とともに混雑している旨の情報を送信する場合に、
前記認証サーバから受信した認証しないことを示す情報および混雑している旨の情報を、認証要求を送信した後の画面に表示する、
ことを特徴とする請求項２０に記載の端末。
【請求項２２】
所定の認証要求およびトークン取得要求を送信する端末と、受信した認証要求に応じて固定のパスワードである第１のパスワードおよび可変のパスワードである第２のパスワードから構成される認証パスワードを用いた認証処理を行いかつ当該第２のパスワードを求めるための規則をユーザごとに記憶する認証サーバと、受信したトークン取得要求に応じてトークンを返信するトークン取得サーバと、前記端末と前記トークン取得サーバとの間の通信を中継する検出装置と、を備える認証システムにおける認証方法であって、
前記検出装置が、前記トークン取得サーバから所定の周期で受信する当該トークン取得サーバの混雑状態に基づいて、前記端末から受信したトークン取得要求をトークン取得サーバへ転送するかどうかを判断する判断ステップと、
前記端末が、前記トークン取得サーバから前記検出装置経由で受信したトークン、および前記規則に基づいて前記第２のパスワードを決定し、前記第１のパスワードおよび当該第２のパスワードから認証パスワードを生成する認証パスワード生成ステップと、
前記端末が、前記所定の認証要求として、前記認証パスワードを含む認証要求を前記認証サーバへ送信する認証要求送信ステップと、
を含むことを特徴とする認証方法。
【請求項２３】
前記検出装置が、前記トークン取得サーバの混雑状態を記憶するための管理テーブルを備える場合、
前記判断ステップでは、前記端末からトークン取得要求を受信した場合に前記管理テーブルに記憶されたトークン取得サーバの混雑状態を確認し、混雑状態を表す値が所定の閾値よりも大きい場合には、前記トークン取得サーバへトークン取得要求を転送しないと判断しかつ混雑している旨の情報を前記端末へ送信し、一方、混雑状態を表す値が所定の閾値以下の場合には、前記トークン取得サーバへトークン取得要求を転送すると判断し、かつ、トークン取得要求を当該トークン取得サーバへ転送するための処理およびその応答として当該トークン取得サーバから受信したトークンを前記端末へ転送する、
ことを特徴とする請求項２２に記載の認証方法。
【請求項２４】
さらに、
前記端末が、前記検出装置から混雑している旨の情報を受信した場合に、その内容を、トークン取得要求を送信した後の画面に表示するトークン取得要求画面表示ステップ、
を含むことを特徴とする請求項２３に記載の認証方法。
【請求項２５】
前記管理テーブルに、さらに、最新の混雑状態が前回受信した混雑状態と比較して変化したかどうかを示す状態変化情報を記憶している場合、
前記判断ステップでは、前記トークン取得サーバの混雑状態を表す値が前記所定の閾値以下であればさらに前記状態変化情報を確認し、確認の結果、変化有りのときは、前記トークンとともに混雑状態が緩和した直後である旨を示す情報を送信する、
ことを特徴とする請求項２３または２４に記載の認証方法。
【請求項２６】
さらに、
前記認証サーバが、前記端末から認証要求を受信した場合に、前記検証装置に対して前記トークン取得サーバの混雑状態の取得要求を送信し、その応答として当該混雑状態を受信し、当該トークン取得サーバの混雑状態を表す値が前記所定の閾値よりも大きい場合には、認証しないことを示す情報とともに混雑している旨の情報を前記端末へ送信する混雑状態認証ステップ、
を含むことを特徴とする請求項２３、２４または２５に記載の認証方法。
【請求項２７】
さらに、
前記端末が、前記認証しないことを示す情報および前記混雑している旨の情報を受信した場合に、その内容を、認証要求を送信した後の画面に表示する認証要求画面表示ステップ、
を含むことを特徴とする請求項２６に記載の認証方法。
【請求項２８】
前記管理テーブルに、さらに、前記トークン取得サーバからトークンを取得した端末のＩＰアドレスを記憶している場合、
さらに、
前記認証サーバが、前記端末から認証要求を受信した場合に、前記検証装置に対して、当該端末が受信したトークンと同一のトークンを受信している端末のＩＰアドレスを要求し、その応答として受信したＩＰアドレスと前記認証要求を送信した端末のＩＰアドレスとを比較し、比較の結果、ＩＰアドレスが異なる場合には、エラーメッセージを、前記認証要求を送信した端末へ送信するＩＰアドレス認証ステップ、
を含むことを特徴とする請求項２６または２７に記載の認証方法。
【請求項２９】
前記管理テーブルに、さらに、前記トークン取得サーバが確立しているセッションごとのトラヒック量および当該トラヒックの送信元端末のＩＰアドレスと、異常状態にある端末のＩＰアドレスとを記憶している場合であって、かつ、前記検証装置が、最大のトラヒック量が第１の閾値よりも大きいときに当該トラヒックの送信元端末が異常状態であるとして記憶し、その後、所定の期間にわたって当該端末からのトラヒック量が第２の閾値（第１の閾値＞第２の閾値）よりも小さくなったときに当該異常状態を解除する動作を行う場合において、
さらに、
前記検証装置が、所定の端末からトークン取得要求を受信し、かつ異常状態の端末が記録された状態で、当該所定の端末と当該異常状態の端末とが同一の場合には、当該所定の端末のトラヒックを遮断する第１の異常状態判断ステップと、
前記検証装置が、所定の端末からトークン取得要求を受信し、かつ異常状態の端末が記録された状態で、当該所定の端末と当該異常状態の端末とが異なる場合には、異常状態である旨の情報を当該所定の端末へ返信する第２の異常状態判断ステップと、
前記検証装置が、所定の端末からトークン取得要求を受信し、かつ過去に異常状態であったことを示す記録があった場合には、その旨の情報を当該所定の端末に返信する第３の異常状態判断ステップと、
前記検証装置が、異常状態である旨の情報または過去に異常状態であったことを示す旨の情報を送信するための処理が行う場合に、前記認証サーバに対して前記規則を初期化するための情報を送信する初期化指示ステップと、
前記規則を初期化するための情報を受信した認証サーバが、前記規則を初期化し、その旨の情報を前記トークン取得要求送信元の端末に対して送信する初期化通知ステップと、
を含むことを特徴とする請求項２６、２７または２８に記載の認証方法。
【請求項３０】
前記判断ステップでは、前記トークン取得サーバの混雑状態を前記トークン取得サーバのＣＰＵ負荷に基づいて判断する、
ことを特徴とする請求項２２〜２９のいずれか１つに記載の認証方法。
【請求項３１】
前記判断ステップでは、前記トークン取得サーバの混雑状態を前記トークン取得サーバが確立しているセッション数に基づいて判断する、
ことを特徴とする請求項２２〜２９のいずれか１つに記載の認証方法。

【図１】