JP5718857B2 - 認証用装置及び認証方法 - Google Patents

Description

本発明は、認証用装置及び認証方法に関する。

従来、金融機関などからの正規のメールや正規のＷｅｂサイトを装い、ユーザＩＤ（identifier）やパスワードを詐取する詐欺が発生している。これらは、「釣り」を意味する「fishing」からフィッシング（phishing）詐欺とも呼ばれている。ユーザＩＤやパスワードの搾取は、経済的にも大きな問題であり、無差別的に発生していることから社会的な問題となっている。

フィッシング詐欺の代表的な手口の一例について簡単に説明する。フィッシング詐欺では、金融機関の窓口などにみせかけたメールを悪意の第３者が無差別に送りつけ、メール本文には個人情報を入力するよう促す案内文と、Ｗｅｂページへのリンクを搭載しておく。その後、メールを受信したユーザによりリンクがクリックされると、金融機関の正規のＷｅｂサイトと、個人情報入力用のポップアップウィンドウとが表示される。メインウィンドウに表示されるサイトは「本物」であり、ポップアップページが「偽物」である。本物を見て安心したユーザがポップアップに表示された入力フォームにユーザＩＤやパスワードなどの認証情報を入力して送信すると、悪意の第３者に認証情報が送信される。

なお、コンピュータが、正当性が確認されたラベルと接続先の組み合わせ（以下、署名対象と称する）について、コンピュータの署名鍵を用いて、署名対象についての電子署名を作成するユーザ保護技術がある。その後、ユーザ保護技術では、ユーザ端末は、検証鍵と、署名対象に電子署名が付加された署名付きコードから抽出した電子署名とを用いて、署名付きコードに含まれる署名対象の正当性について検証する。そして、ユーザ保護技術では、ユーザ端末は、実際に接続先に接続する前に、正当性が確認された署名対象をユーザに知らせ、接続先に接続するかどうかをユーザに選択させる。

特開２００７−３０５０５２号公報

しかしながら、上述の技術では、認証情報を不正な要求元に送信することがあるという問題がある。例えば、ユーザが偽物を誤って本物と勘違いし、認証情報を送信してしまう。

開示の技術は、上述に鑑みてなされたものであって、正規の要求元以外に認証情報を送信することを防止可能となる認証用装置及び認証方法を提供することを目的とする。

開示の認証用装置は、一つの態様において、認証情報の入力要求を受信する受信部を備える。また、開示の認証用装置は、一つの態様において、前記受信部により前記入力要求が受信されると、前記入力要求の要求元の装置を識別するための要求元情報を取得する取得部を備える。また、開示の認証用装置は、一つの態様において、前記受信部により前記入力要求が受信されると、前記認証情報と、該認証情報を用いる正規の認証者を識別するための認証者情報との入力を受け付ける受付部を備える。また、開示の認証用装置は、一つの態様において、前記取得部によって取得された前記要求元情報と、前記受付部によって受け付けられた前記認証者情報とが一致するか否かを判定する判定部を備える。また、開示の認証用装置は、一つの態様において、前記判定部によって一致すると判定された場合に、前記受付部によって受け付けられた前記認証情報を前記要求元に送信する送信部を備える。

開示の認証用装置の一つの態様によれば、正規の要求元以外に認証情報を送信することを防止可能となるという効果を奏する。

図１は、第１の実施形態に係るユーザ端末を含む認証システムの一例を示すブロック図である。 図２は、第１の実施形態に係るユーザ端末の構成の一例を示すブロック図である。 図３は、第１の実施形態における第１の入力領域と第２の入力領域との一例について示す図である。 図４は、第１の実施形態におけるサーバ証明書の一例を示す図である。 図５は、第１の実施形態におけるアドレスバーの一例を示す図である。 図６は、第１の実施形態における警告部により出力される警告の一例を示す図である。 図７は、第１の実施形態に係るユーザ端末による処理の流れの一例を示すシーケンス図である。 図８は、第１の実施形態に係るユーザ端末による処理の流れの一例を示すシーケンス図である。 図９は、認証用装置による処理を実行するための認証プログラムによる情報処理がコンピュータを用いて具体的に実現されることを示す図である。

以下に、開示の認証用装置及び認証方法の実施形態について、図面に基づいて詳細に説明する。なお、本実施形態により開示する発明が限定されるものではない。各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

(第１の実施形態）
［認証用装置の構成］
図１は、第１の実施形態に係るユーザ端末を含む認証システムの一例を示すブロック図である。ユーザ端末１００は、例えば、ネットワーク１０を介して要求元サーバ２００と接続される。ユーザ端末１００は、要求元サーバ２００により認証情報が要求されると、以下に詳細に説明する一連の処理を実行することで、認証情報を要求元サーバ２００に送信したりしなかったりする。ユーザ端末１００は、認証用端末とも称する。

なお、図１に示す例では、説明の便宜上、１つのユーザ端末１００と、１つの要求元サーバ２００とを示したが、これに限定されるものではなく、ユーザ端末１００が複数あっても良く、要求元サーバ２００が複数あっても良い。

認証情報の要求元となる要求元サーバ２００とは、例えば、任意のサーバである。要求元サーバ２００は、例えば、認証情報を用いる正規の認証者に用いられるサーバであったり、悪意の第３者により用いられるサーバであったりする。正規の認証者に用いられるサーバとは、例えば、正規の金融機関により運用されているサーバである。また、悪意の第３者により用いられるサーバとは、例えば、フィッシング詐欺によりユーザから認証情報の取得を試みる第３者により運用されるサーバである。なお、要求元サーバ２００により送受信される情報の詳細については、ここでは説明を省略し、ユーザ端末１００の説明に併せて適宜説明する。

以下では、正規の認証者によって、認証情報と、認証情報を用いる正規の認証者を識別するための認証者情報とが、ユーザ端末１００を利用するユーザに通知されている場合を用いて説明する。例えば、正規の認証者によって認証情報と認証者情報とが郵送されている場合を用いて説明する。なお、ここで、認証情報と認証者情報とは、関連付けられている。

また、以下では、認証情報には、ユーザ識別情報と認証用情報とが含まれる場合を用いて説明する。ユーザ識別情報とは、例えば、正規の金融機関のサイトにログインするためのユーザＩＤである。また、認証用情報とは、例えば、正規の金融機関のサイトにログインするためのパスワードである。また、認証用情報は、入力要求を受信した際に要求元を識別する情報として取得可能な情報であれば良く、任意の情報を用いて良い。認証用情報は、例えば、関連付けられている認証情報を用いる正規の認証者により用いられるサイトやサーバのＵＲＬ（Uniform Resource Locator）に関するＵＲＬ情報である。

図２は、第１の実施形態に係るユーザ端末の構成の一例を示すブロック図である。図２に示す例では、ユーザ端末１００は、通信部１０１と、入出力部１０２と、記憶部１１０と、制御部１２０とを有する。

通信部１０１は、制御部１２０と接続される。通信部１０１は、他の装置とネットワークを介して情報の送受信を行う。通信部１０１によって送受信される情報の詳細については、後述するため説明を省略する。

入出力部１０２は、制御部１２０と接続される。入出力部１０２は、情報や指示を利用者から受け付け、受け付けた情報や指示を制御部１２０に入力する。入出力部１０２は、キーボードやマウス、マイクなどが該当する。また、入出力部１０２は、制御部１２０から情報を受け付け、受け付けた情報を出力する。入出力部１０２は、例えば、キーボードやマウス、マイク、モニタ、スピーカなどである。入出力部１０２によって受け付けられる情報や指示の詳細や、入出力部１０２によって出力される情報の詳細については、後述するため説明を省略する。入出力部１０２は、「表示部」とも称する。

記憶部１１０は、制御部１２０と接続される。記憶部１１０は、制御部１２０による各種処理に用いるデータを記憶する。記憶部１１０は、例えば、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、フラッシュメモリ（Flash Memory）などの半導体メモリ素子、又は、ハードディスクや光ディスクなどである。

制御部１２０は、通信部１０１、入出力部１０２及び記憶部１１０と接続される。制御部１２０は、各種の処理手順などを規定したプログラムを記憶する内部メモリを有し、種々の処理を制御する。制御部１２０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）などである。図２に示す例では、制御部１２０は、受信部１２１と、取得部１２２と、受付部１２３と、判定部１２４と、送信部１２５と、警告部１２６とを有する。

受信部１２１は、認証情報の入力要求を受信する。具体的には、受信部１２１は、通信部１０１を介して認証情報の入力要求を受信する。例えば、受信部１２１は、ユーザ識別情報の入力を受け付けるための第１の入力領域と、認証用情報の入力を受け付けるための第２の入力領域とを表示部から表示する表示要求を入力要求として受信する。なお、以下では、受信部１２１が、入力要求に加えて、入力要求の要求元のサーバを照明するサーバ証明書を受信する場合を例に説明するが、これに限定されるものではない。

図３は、第１の実施形態における第１の入力領域と第２の入力領域との一例について示す図である。図３に示す例では、受信部１２１は、ユーザＩＤの入力をユーザから受け付ける第１の入力領域３０１と、パスワードの入力をユーザから受け付ける第２の入力領域３０２とを表示する表示要求を受信する。なお、図３に示す例では、第１の入力領域３０１と第２の入力領域３０２とに加えて、第１の入力領域３０１と第２の入力領域３０２とに入力された情報を要求元に送信するトリガとなるトリガ領域３０３を併せて示した。図３に示す場合、トリガ領域３０３がユーザによってクリックされると、第１の入力領域３０１に入力された情報と、第２の入力領域３０２に入力された情報とが要求元に送信される。なお、後述するように、図３に示す例において、第１の実施形態におけるユーザ端末１００では、ユーザによってトリガ領域３０３がクリックされたとしても、直ぐに情報が送信されることはなく、後述する一連の処理の結果、送信されたり送信されなかったりする。

また、表示要求によって表示される第１の入力領域と第２の入力領域とは、入出力部１０２の表示面全面に表示されても良く、ポップアップのような形で表示面の一部分に表示されても良い。

受信部１２１によって入力要求が受信されるきっかけについて説明する。受信部１２１は、例えば、入力要求を送信するＷｅｂサイトのＵＲＬがユーザによって指定されると、指定されたＵＲＬのＷｅｂサイトから入力要求を受信する。例えば、受信部１２１は、ユーザによって正規の金融機関のＷｅｂサイトが指定されると、正規の金融機関のＷｅｂサイトから入力要求を受信する。また、例えば、悪意の第３者がフィッシングメールをユーザに送信し、送信されたメールに記載されたＵＲＬをユーザがクリックすると、受信部１２１は、ユーザによってクリックされたＵＲＬのＷｅｂサイトから入力要求を受信する。

取得部１２２は、受信部１２１により入力要求が受信されると、入力要求の要求元の装置を識別するための要求元情報を取得する。ここで、要求元情報とは、認証者情報と一致しているか判定される情報であり、判定可能な任意の情報であって良い。要求元情報は、例えば、ＵＲＬ（Uniform Resource Locator）に関するＵＲＬ情報である。

例えば、取得部１２２は、受信部１２１によりサーバ証明書が受信されている場合には、要求元のサーバ証明書を取得し、取得したサーバ証明書から要求元に関するＵＲＬ情報を要求元情報として取得する。

図４は、第１の実施形態におけるサーバ証明書の一例を示す図である。図４に示す例では、サーバ証明書は、サーバ証明書の発行先のCommon Name（ＣＮ）として「www.patent.co.jp」を含む。また、図４のサーバ証明書は、サーバ証明書の発行先のOrganization（Ｏ）として「patent Ltd.」を含む。また、図４のサーバ証明書は、サーバ証明書の発行先のOrganization Unit（ＯＵ）として「ＣＪＬ ０２」を含む。なお、図４のサーバ証明書は、サーバ証明書の発行先について、Serial Numberを含み、サーバ証明書の発行元について、Common Name（ＣＮ）とOrganization（Ｏ）とOrganization Unit（ＯＵ）とを含み、サーバ証明書の有効性について、Issued On とExpired Onとを含み、サーバ証明書のFingerprintとしてSHA1 FingerprintとMD5 Fingerprintとを含む場合を例に示した。なお、図４では、記載の便宜上、サーバ証明書の発行先のCommon Name（ＣＮ）とOrganization（Ｏ）とOrganization Unit（ＯＵ）とを除き、値が入力されていない例を示したが、実際には、値が入力されている。また、図４に示すサーバ証明書は、一例であり、図４に示されている項目の一部がないサーバ証明書や、図４に示されている項目以外の項目が加わっているサーバ証明書であっても良い。

図４に示す例を用いて説明すると、取得部１２２は、サーバ証明書からCommon Name（ＣＮ）を取得する。図４に示す場合、取得部１２２は、「www.patent.co.jp」を要求元情報として取得する。言い換えると、取得部１２２は、サーバ証明書から通信先を示すCommon Nameを取得する。

なお、以下では、サーバ証明書のCommon Nameの文字列をそのまま認証者情報や要求元情報として用いる場合を例に説明する。すなわち、認証者情報が、「www.patent.co.jp」である場合を用いて説明する。ただし、これに限定されるものではない。具体的には、ユーザが予め把握可能であり、入力情報を受信した際に、要求元サーバ２００を識別するための情報としてユーザ端末１００が取得可能な情報であれば、任意の情報を用いて良い。例えば、図５に示すように、ブラウザのアドレスバーに表示されるＵＲＬ文字列を認証者情報や要求元情報として用いても良く、ブラウザのアドレスバーに表示されるＵＲＬ文字列のうち、ホストネーム部分を認証者情報や要求元情報として用いても良く。図５は、第１の実施形態におけるアドレスバーの一例を示す図である。また、サーバ証明書に含まれる情報を認証者情報や要求元情報として用いる場合、Common Name（ＣＮ）ではなく、Organization（Ｏ）を用いても良く、Common Name（ＣＮ）とOrganization（Ｏ）との組み合わせを用いても良く、サーバ証明書内の情報のうち任意の情報を用いて良い。

受付部１２３は、受信部１２１により入力要求が受信されると、認証情報と、認証情報を用いる正規の認証者を識別するための認証者情報との入力を受け付ける。具体的には、受付部１２３は、ユーザ識別情報と認証用情報と認証者情報との入力をユーザから入出力部１０２を介して受け付ける。また、受付部１２３は、認証者情報として、認証情報を用いてユーザを認証する正規の認証者に関するＵＲＬ情報の入力とをユーザから受け付ける。

例えば、受付部１２３は、受信部１２１により受信された表示指示に従って第１の入力領域と第２の入力領域とを表示する。そして、受付部１２３は、表示部により表示された第１の入力領域からユーザ識別情報の入力を受け付け、表示部により表示された第２の入力領域から認証用情報と認証者情報とを両者が区別可能な入力状態で受け付ける。

ここで、認証用情報と認証者情報とを受け付ける点について更に説明する。ユーザ端末１００は、ユーザによって入力された情報のうち、いずれが認証者情報であるかを識別する必要がある。すなわち、いわゆるフィッシング詐欺を目的として設立されたフィッシングサイトであろうと、正規のＷｅｂサイトであろうとも、入力画面に依存せず、認証者情報を区別する必要がある。

ここで、秘密情報となるパスワードなどの認証用情報を入力フォームで入力する場合、パスワードフォームが用いられる。パスワードフォームでは、入力された文字列が表示されず、例えば、「***」といった状態で表示される。また、パスワードフォーム以外において認証用情報の入力を受け付ける場合、入力領域に対して種々の情報が入力されることになり、入力された情報のうち認証者情報を識別することが困難になると考えられる。このことを踏まえ、認証用情報が入力される一方他の情報が入力される可能性が低いパスワードフォームの入力領域に、パスワードと認証用情報とを所定の入力ルールに従って入力されるという構成を採用する。

なお、入力領域は、例えば、以下のような記述により実現される。
（１）<input type="text" id="username" Name="username" size="12" tabindex="1"
（２）<input type="password" id="password" Name="password" tabindex="2" size="18" maxlength="50" value="" class="soInput"
上記の例では、「input type="password"」となっている（２）がパスワードフォームとなる。この結果、受付部１２３は、（２）により実現される図３の第２の入力領域３０２において、認証用情報と認証者情報との入力を受け付ける。

なお、認証用情報と認証者情報とを入力するフォーマットは、予め標準化されているなどで、ユーザ端末１００が把握していても良く、入力指示を任意の手法により解析することでパスワードフォームを識別して用いても良い。

パスワードと認証用情報とを入力するための入力ルールの一例について説明する。ここで、入力ルールは、例えば、認証用情報と認証者情報との入力順や、認証用情報と認証者情報とを区別する手法を規定する。例えば、認証用情報と認証者情報との入力順で入力し、認証用情報と認証者情報とが「＠」によって区別されるという入力ルールの場合を例に説明する。

例えば、受付部１２３は、第１の入力領域において「１２３４５６７８９」の入力を受け付け、第２の入力領域において「pcF6vZeq@www.patent.co.jp」の入力を受け付ける。この場合、第１の入力領域に入力された「１２３４５６７８９」がユーザ識別情報となり、第２の入力領域に入力された情報のうち、「pcF6vZeq」が認証用情報となり、「www.patent.co.jp」が認証者情報となる。

ただし、入力ルールは、これに限定されるものではなく、認証用情報と認証者情報とを区別できれば任意のルールであって良い。入力ルールは、認証用情報と認証者情報とを入力するユーザと、ユーザ端末１００との両者が予め把握しているものとして説明する。

判定部１２４は、取得部１２２によって取得された要求元情報と、受付部１２３によって受け付けられた認証者情報とが一致するか否かを判定する。具体的には、判定部１２４は、受付部１２３によって第２の入力領域から受け付けられた認証用情報と認証者情報とのうち認証者情報を識別し、識別した認証者情報と取得部１２２によって取得された認証者情報とが一致するか否かを判定する。例えば、判定部１２４は、取得部１２２によって取得されたＵＲＬと、受付部１２３によって受け付けられたＵＲＬ情報とが一致するか否かを判定する。

受付部１２３により、第２の入力領域において「pcF6vZeq@www.patent.co.jp」の入力が受け付けられた場合を例に説明する。また、取得部１２２により取得された要求元情報が「www.patent.co.jp」である場合を用いて説明する。この場合、判定部１２４は、「pcF6vZeq@www.patent.co.jp」のうち入力ルールに基づいて認証者情報「www.patent.co.jp」を識別し、識別した認証者情報「www.patent.co.jp」と要求元情報「www.patent.co.jp」とを比較し、一致すると判定する。一方、例えば、取得部１２２により取得された要求元情報が「www.patent.biz」である場合には、判定部１２４は、一致しないと判定する。

送信部１２５は、判定部１２４によって一致すると判定された場合に、受付部１２３によって受け付けられた認証情報を要求元に送信する。例えば、送信部１２５は、受付部１２３によって入力が受け付けられたユーザ識別情報「１２３４５６７８９」と認証用情報「pcF6vZeq」とを認証情報として要求元サーバ２００に送信する。

警告部１２６は、判定部１２４によって一致しないと判定された場合に、ユーザに警告する。例えば、警告部１２６は、図６に示すように、フィッシングの恐れがある旨や、入力された認証情報の送信を中断する旨のメッセージ３０４を表示しても良い。図６は、第１の実施形態における警告部により出力される警告の一例を示す図である。ただし、警告部１２６により出力される警告は図６に示される場合に限定されるものではなく、任意の情報を任意の手法にて出力して良い。

なお、ユーザ端末１００は、既知のパーソナルコンピュータ、ワークステーション、携帯電話、ＰＨＳ（Personal Handyphone System）端末、移動体通信端末又はＰＤＡ（Personal Digital Assistant）などの情報処理装置を利用して実現しても良い。例えば、ＰＤＡなどの情報処理装置に、図２に示した制御部１２０の各機能を搭載することによって実現しても良い。

［認証用装置による処理］
第１の実施形態におけるユーザ端末１００による処理の流れの一例について説明する。以下では、説明の便宜上、正規の認証者により認証情報が要求された場合における処理の流れの一例と、悪意の第３者により認証情報が要求された場合における処理の流れの一例とを順に説明する。

［正規の認証者により認証情報が要求された場合における処理］
図７は、第１の実施形態に係るユーザ端末による処理の流れの一例を示すシーケンス図である。図７に示す例では、正規の認証者により認証情報が要求された場合における処理の流れの一例を示す。なお、シーケンス図では、ユーザ識別情報を「ＩＤ」と記載し、認証用情報を「ＰＷＤ」と記載し、認証者情報を「Ｖｅｒｉｆｉｅｒ」と記載し、要求元情報を「ＣＮ」と記載する。また、要求元情報として、サーバ証明書のCommon Nameを用いる場合を例に説明する。

図７に示すように、要求元サーバ２００によって入力要求とサーバ証明書とが送信されると（ステップＳ１０１）、ユーザ端末１００は、認証情報の入力要求とサーバ証明書とを受信する（ステップＳ１０２）。ここで、サーバ証明書には、ＣＮ（Common Name）が含まれているものとして説明する。

そして、ユーザ端末１００は、サーバ証明書から通信先（ＣＮ）を抽出する（ステップＳ１０３）。例えば、ユーザ端末１００は、ＣＮ「www.patent.co.jp」を取得する。つまり、ユーザ端末１００は、入力要求が受信されると、入力要求の要求元の装置を識別するための要求元情報を取得する。

また、その後、ユーザ識別情報と認証用情報と認証者情報とをユーザが入力すると（ステップＳ１０４）、ユーザ端末１００は、入力されたユーザ識別情報と認証用情報と認証者情報とを受け付ける（ステップＳ１０５）。つまり、ユーザ端末１００は、例えば、受付部１２３は、受信部１２１により受信された表示指示に従って第１の入力領域と第２の入力領域とを表示する。そして、受付部１２３は、表示部により表示された第１の入力領域からユーザ識別情報の入力を受け付け、表示された第２の入力領域から認証用情報と認証者情報とを両者が区別可能な入力状態で受け付ける。例えば、受付部１２３は、第１の入力領域において「１２３４５６７８９」の入力を受け付け、第２の入力領域において「pcF6vZeq@www.patent.co.jp」の入力を受け付ける。

そして、判定部１２４は、ＶｅｒｉｆｉｅｒとＣＮとが一致するか否かを判定する（ステップＳ１０６）。つまり、ユーザ端末１００は、取得部１２２によって取得された要求元情報と、受付部１２３によって受け付けられた認証者情報とが一致するか否かを判定する。図７に示す場合には、ＶｅｒｉｆｉｅｒとＣＮとは共に「www.patent.co.jp」であり、一致すると判定する。

そして、送信部１２５は、判定部１２４によって一致すると判定された場合に、受付部１２３によって受け付けられた認証情報を要求元に送信する（ステップＳ１０７）。例えば、送信部１２５は、ユーザ識別情報「１２３４５６７８９」と認証用情報「pcF6vZeq」とを要求元サーバ２００に送信する。その後、要求元サーバ２００は、認証情報が正しい場合には、ＯＫである旨を送信する（ステップＳ１０８）。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、上記のステップＳ１０４及びＳ１０５の後に、ステップＳ１０３を実行しても良い。

［悪意の第３者により認証情報が要求された場合における処理］
図８は、第１の実施形態に係るユーザ端末による処理の流れの一例を示すシーケンス図である。図８に示す例では、悪意の第３者により認証情報が要求された場合における処理の流れの一例を示す。なお、以下では、図７とは異なる点について重点的に説明する。また、図８に示す例では、悪意の第３者がフィッシングメールを送信し、送信されたメールに記載されたＵＲＬをユーザがクリックした場合を例に説明するが、これに限定されるものではない。

図８に示すように、悪意の第３者によってフィッシングメール等が送信され（ステップＳ２０１）、ユーザによってフィッシングメールに記載されたＵＲＬがクリックされると（ステップＳ２０２）、ユーザ端末１００は、フィッシングメールに記載されたＵＲＬへのアクセス要求を要求元サーバ２００に送信する（ステップＳ２０３）。

そして、要求元サーバ２００によって入力要求とサーバ証明書とが送信されると（ステップＳ２０４）、ユーザ端末１００は、認証情報の入力要求とサーバ証明書とを受信する（ステップＳ２０５）。

そして、ユーザ端末１００は、サーバ証明書から通信先（ＣＮ）を抽出する（ステップＳ２０６）。例えば、ユーザ端末１００は、ＣＮ「www.patent.biz」を取得する。

そして、ユーザ識別情報と認証用情報と認証者情報とをユーザが入力すると（ステップＳ２０７）、ユーザ端末１００は、入力されたユーザ識別情報と認証用情報と認証者情報とを受け付ける（ステップＳ２０８）。例えば、受付部１２３は、第１の入力領域において「１２３４５６７８９」の入力を受け付け、第２の入力領域において「pcF6vZeq@www.patent.co.jp」の入力を受け付ける。

そして、判定部１２４は、ＶｅｒｉｆｉｅｒとＣＮとが一致するか否かを判定する（ステップＳ２０９）。つまり、ユーザ端末１００は、取得部１２２によって取得された要求元情報と、受付部１２３によって受け付けられた認証者情報とが一致するか否かを判定する。図８に示す場合には、Ｖｅｒｉｆｉｅｒが「www.patent.co.jp」である一方、ＣＮは「www.patent.biz」であり、一致しないと判定する。

そして、警告部１２６は、判定部１２４によって一致しないと判定された場合に、警告表示を行う（ステップＳ２１０）。この場合、送信部１２５は、認証情報を送信しない。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、上記のステップＳ２０７及びＳ２０８の後にＳ２０６を実行しても良い。

［第１の実施形態の効果］
上述したように、
+によれば、ユーザ端末１００は、認証情報の入力要求を受信する。また、入力要求を受信すると、入力要求の要求元の装置を識別するための要求元情報を取得する。また、入力要求を受信すると、認証情報と、認証情報を用いる正規の認証者を識別するための認証者情報との入力を受け付ける。また、ユーザ端末１００は、取得した要求元情報と、受け付けた認証者情報とが一致するかを判定し、一致すると判定された場合に、受け付けた認証情報を要求元に送信する。この結果、正規の要求元以外に認証情報を送信することを防止可能となる。

フィッシングは、メールなどでＵＲＬが広まってから３０分程度が勝負といわれており、それくらいの短時間で被害が発生する。この結果、人手での対策は後手にまわることがある。このことを踏まえ、上述したユーザ端末１００によれば、認証者情報を用いて、通信先と認証者情報の同一性を確認して通信先を制限することで、安全な通信先であるかどうかを確認後に、認証情報を送信する。この結果、人間が目視で入力先の本物・偽物かを確認せざるを得ない手法と比較して、簡単かつ確実に正規の要求元以外に認証情報を送信することを防止可能となる。

また、第１の実施形態によれば、一致しないと判定された場合に、ユーザに警告するので、不正な要求元からの認証要求である場合にユーザに警告することが可能となる。

また、第１の実施形態によれば、ユーザ端末１００は、表示部を更に備え、認証情報には、ユーザ識別情報と認証用情報とが含まる。また、ユーザ端末１００は、ユーザ識別情報の入力を受け付けるための第１の入力領域と、認証用情報の入力を受け付けるための第２の入力領域とを表示部から表示する表示要求を入力要求として受信する。また、ユーザ端末１００は、表示部により表示された第１の入力領域からユーザ識別情報の入力を受け付け、表示部により表示された第２の入力領域から認証用情報と認証者情報とを両者が区別可能な入力状態で受け付ける。また、ユーザ端末１００は、第２の入力領域から受け付けられた認証用情報と認証者情報とのうち認証者情報を識別し、識別した認証者情報と取得部によって取得された認証者情報とが一致するか否かを判定する。この結果、数ある領域の中から認証用情報と認証者情報とが入力された領域を識別可能となり、安全な要求先にのみ認証情報を送信することが可能となる。

例えば、認証情報を入力する領域は、フォームで入力する場合、パスワードフォーム（入力結果の表示が＊＊＊になるフォーム）が使われる。この結果、予め、パスワードフォームを把握しておくことで、入力画面に複数の領域が含まれていたとしても、認証用情報と認証者情報とが入力される領域を識別可能となり、如何なる入力画面においても、認証者情報を用いた判定処理が実行可能となる。

また、第１の実施形態によれば、要求元情報と認証者情報とは、ＵＲＬに関するＵＲＬ情報であって、ユーザ端末１００は、要求元のサーバ証明書を取得し、取得したサーバ証明書から要求元に関するＵＲＬ情報を要求元情報として取得する。また、ユーザ端末１００は、認証情報と、認証情報を用いてユーザを認証する正規の認証者に関するＵＲＬ情報の入力とをユーザから受け付ける。また、ユーザ端末１００は、取得したＵＲＬと、受け付けたＵＲＬ情報とが一致するか否かを判定する。この結果、正規の要求元以外に認証情報を送信することを防止可能となる。

（第２の実施形態）
さて、これまで本発明の実施形態について説明したが、本発明は上述した実施形態以外にも、その他の実施形態にて実施されても良い。そこで、以下では、その他の実施形態を示す。

［システム構成］
また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報（図１から図８）については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、図２において、入出力部１０２を外部装置としてネットワーク経由で接続するようにしても良い。この場合、ユーザによって入力された情報は、ネットワークを経由してユーザ端末１００に入力される。

［プログラム］
図９は、認証用装置による処理を実行するための認証プログラムによる情報処理がコンピュータを用いて具体的に実現されることを示す図である。図９に例示するように、コンピュータ３０００は、例えば、メモリ３０１０と、ＣＰＵ（Central Processing Unit）３０２０と、ネットワークインタフェース３０７０と、ハードディスクドライブ３０８０とを有する。コンピュータ３０００の各部はバス３１００によって接続される。

メモリ３０１０は、図９に例示するように、ＲＯＭ３０１１及びＲＡＭ３０１２を含む。ＲＯＭ３０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。

ここで、図９に例示するように、ハードディスクドライブ３０８０は、例えば、ＯＳ３０８１、アプリケーションプログラム３０８２、プログラムモジュール３０８３、プログラムデータ３０８４を記憶する。すなわち、開示の技術に係る更新プログラムは、コンピュータ３０００によって実行される指令が記述されたプログラムモジュール３０８３として、例えばハードディスクドライブ３０８０に記憶される。具体的には、上記実施形態で説明した制御部１２０の各部と同様の情報処理を実行する手順各々が記述されたプログラムモジュール３０８３が、ハードディスクドライブ３０８０に記憶される。

また、上記実施形態で説明した認証プログラムによる情報処理に用いられるデータは、プログラムデータ３０８４として、例えばハードディスクドライブ３０８０に記憶される。そして、ＣＰＵ３０２０が、ハードディスクドライブ３０８０に記憶されたプログラムモジュール３０８３やプログラムデータ３０８４を必要に応じてＲＡＭ３０１２に読み出し、各種の手順を実行する。

なお、認証プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ハードディスクドライブ３０８０に記憶される場合に限られない。例えば、プログラムモジュール３０８３やプログラムデータ３０８４は、着脱可能な記憶媒体に記憶されても良い。この場合、ＣＰＵ３０２０は、ディスクドライブなどの着脱可能な記憶媒体を介してデータを読み出す。また、同様に、認証プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されても良い。この場合、ＣＰＵ３０２０は、ネットワークインタフェースを介して他のコンピュータにアクセスすることで各種データを読み出す。

［その他］
なお、本実施形態で説明した認証プログラムは、インターネットなどのネットワークを介して配布することができる。また、認証プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１０ ネットワーク
１００ ユーザ端末
１０１ 通信部
１０２ 入出力部
１１０ 記憶部
１２０ 制御部
１２１ 受信部
１２２ 取得部
１２３ 受付部
１２４ 判定部
１２５ 送信部
１２６ 警告部
２００ 要求元サーバ

Claims (5)

1. 認証情報の入力要求を受信する受信部と、
   前記受信部により前記入力要求が受信されると、前記入力要求の要求元の装置を識別するための要求元情報を取得する取得部と、
   前記受信部により前記入力要求が受信されると、前記認証情報と、該認証情報を用いる正規の認証者を識別するための認証者情報との入力を受け付ける受付部と、
   前記取得部によって取得された前記要求元情報と、前記受付部によって受け付けられた前記認証者情報とが一致するか否かを判定する判定部と、
   前記判定部によって一致すると判定された場合に、前記受付部によって受け付けられた前記認証情報を前記要求元に送信する送信部と
   を備えたことを特徴とする認証用装置。
2. 前記判定部によって一致しないと判定された場合に、警告を出力する警告部を更に備えることを特徴とする請求項１に記載の認証用装置。
3. 前記認証用装置は、表示部を更に備え、
   前記認証情報には、ユーザ識別情報と認証用情報とが含まれ、
   前記受信部は、前記ユーザ識別情報の入力を受け付けるための第１の入力領域と、前記認証用情報の入力を受け付けるための第２の入力領域とを前記表示部から表示する表示要求を前記入力要求として受信し、
   前記受付部は、前記表示部により表示された前記第１の入力領域から前記ユーザ識別情報の入力を受け付け、前記表示部により表示された前記第２の入力領域から前記認証用情報と前記認証者情報とを両者が区別可能な入力状態で受け付け、
   前記判定部は、前記受付部によって前記第２の入力領域から受け付けられた前記認証用情報と前記認証者情報とのうち前記認証者情報を識別し、識別した前記認証者情報と前記取得部によって取得された前記認証者情報とが一致するか否かを判定することを特徴とする請求項１又は２に記載の認証用装置。
4. 前記要求元情報と前記認証者情報とは、ＵＲＬ（Uniform Resource Locator）に関するＵＲＬ情報であって、
   前記取得部は、前記要求元のサーバ証明書を取得し、取得したサーバ証明書から前記要求元に関するＵＲＬ情報を前記要求元情報として取得し、
   前記受付部は、前記認証情報と、該認証情報を用いて前記ユーザを認証する正規の認証者に関するＵＲＬ情報の入力とを前記ユーザから受け付け、
   前記判定部は、前記取得部によって取得されたＵＲＬと、前記受付部によって受け付けられたＵＲＬ情報とが一致するか否かを判定することを特徴とする請求項１〜３のいずれか１項に記載の認証用装置。
5. 認証情報の入力要求を受信する受信工程と、
   前記受信工程により前記入力要求が受信されると、前記入力要求の要求元の装置を識別するための要求元情報を取得する取得工程と、
   前記受信工程により前記入力要求が受信されると、前記認証情報と、該認証情報を用いる正規の認証者を識別するための認証者情報との入力を受け付ける受付工程と、
   前記取得工程によって取得された前記要求元情報と、前記受付工程によって受け付けられた前記認証者情報とが一致するか否かを判定する判定工程と、
   前記判定工程によって一致すると判定された場合に、前記受付工程によって受け付けられた前記認証情報を前記要求元に送信する送信工程と
   を含んだことを特徴とする認証方法。

Images