JP6506384B2 - サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム - Google Patents

サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム Download PDF

Info

Publication number
JP6506384B2
JP6506384B2 JP2017252047A JP2017252047A JP6506384B2 JP 6506384 B2 JP6506384 B2 JP 6506384B2 JP 2017252047 A JP2017252047 A JP 2017252047A JP 2017252047 A JP2017252047 A JP 2017252047A JP 6506384 B2 JP6506384 B2 JP 6506384B2
Authority
JP
Japan
Prior art keywords
user
information
database
blacklist
legitimate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017252047A
Other languages
English (en)
Other versions
JP2018063728A (ja
Inventor
敦好 島津
敦好 島津
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CAULIS INC.
Original Assignee
CAULIS INC.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by CAULIS INC. filed Critical CAULIS INC.
Priority to JP2017252047A priority Critical patent/JP6506384B2/ja
Publication of JP2018063728A publication Critical patent/JP2018063728A/ja
Application granted granted Critical
Publication of JP6506384B2 publication Critical patent/JP6506384B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、ユーザに対して所定のサービスを提供するサービス提供システム・提供方法に関する。また、当該サービス提供システムがユーザの認証に利用する照合装置・照合方法に関する。さらに、これら装置に関連するコンピュータプログラムに関する。
従来、インターネットなどのネットワーク上でユーザに対して種々のサービスを提供するWebサイト(サービス提供システム)が知られている。
このWebサイトを利用したいユーザは、与えられているIDとパスワートを用いて、Webサイトにアクセス・ログインを行い、Webサイトを利用して所望のサービスを受けることができる。
例えば、ショッピングモールのWebサイトを利用するユーザは、IDとパスワードを利用してそのWebサイトにログインし、そのWebサイトが提供する各ページを移動し、所望の商品を見つけることができたページで商品の購入を実行することができる。
従来のWebサイトにおいては、正規のユーザのみが利用可能にするために、IDとパスワードが利用される場合が多い。このIDとパスワードとを利用することによって、いわゆる悪意の侵入者を排除することができ、円滑なサービスの利用を図ることができると考えられている。
<悪意のアクセス>
しかし、近年、悪意のある第三者が不正な手段を用いて他人のIDとパスワードとを入手する事件が報告されている。このように悪意のある第三者が(正規のユーザである)他人のIDとパスワードを用いて、Webサイトにログインした場合、そのIDとパスワードだけでは、そのログイン者が、正規のユーザか、悪意のある第三者かを区別することは困難である。
そこで、近年、正規のユーザが実行するログイン以降の動作の情報を記録しておき、ホワイトリストとしてデータベース化しておく仕組みが知られている。ここで、記録する動作の情報としては、例えば、下記のような情報が好ましい。
・OS
・ブラウザ
・言語
・IPアドレス(アクセスを実行しているユーザの地理的な位置を表す)
・時間(アクセスした時刻)
これらの情報を記録し、いわゆるホワイトリスト(WhiteList)としてデータベースを構築しておけば、ログインしてきたユーザがいつもと異なる動作をとっていることを検知することが可能である。このように、いつもと異なる動作をとるユーザに対しては、悪意のある第三者ではないことを確認するため、追加認証を実行することが好ましい。例えば、ユーザの携帯電話やスマートホン等に対して、「現在貴方のIDを用いて以下のWebサイトへのアクセスが行われています。このアクセスは貴方自身によるものですか。そうでない場合は、NOボタンを押下(タッチ)してください」というメッセージを送り、「NOボタン」が押された(タッチされた)場合は、正規のユーザではなく、悪意のある第三者がアクセスしていると判断することができる。そして、直ちに当該ユーザのアクセスを切断する処理をとることができる。
例えば、いつもとは別の場所(IPアドレス)からアクセスされた場合や、いつもとは異なるパソコン(OS、ブラウザ)からアクセスされた場合等が挙げられる。このような場合に、追加認証が実行されて、正規のユーザか否かが確認される(本人確認とも呼ばれる)。
また、ホワイトリストは、当該正規のユーザによる過去の数10回程度のアクセスに基づき構築される場合が多いが、より少ない場合もあり(数回)、またより多い場合(数100回)もある。さらに、ホワイトリストは、正規のユーザがアクセスする度に新しい情報と置き換えられ、更新されるように構成される場合もある。
先行特許文献
例えば、下記特許文献1には、ホワイトリストと、ブラックリストとを用いて、コンテンツの情報を検索する装置が開示されている。両リストを用いることによって、プライバシーが保護されると同文献には記載されている。
また、例えば、下記特許文献2には、ホワイトリストと、ブラックリストとを用いて、Webサイトへのアクセスを制御するアクセス制御システムが開示されている。
特開2012−159939号公報 特開2011−3132号公報
このように、従来のWebサイトにおいては、正規のユーザのアクセスの動作の情報をホワイトリストとして記録しておき、このホワイトリストと大きく異なる動作をとるユーザに対しては適宜追加認証を行っていた。
しかし、悪意のある第三者は、当然巧妙に正規のユーザ本人になりすましているので、それを見破ることは一般に困難であることもある。したがって、セキュリティ担当者の経験則によって対処している場合も多い。例えば、金融機関のWebサイトにおける預金口座からの引き出し限度額一杯の預金の引き出しは、悪意のある第三者である可能性が高い等の経験則に頼り、悪意のある第三者を発見している場合もある。
さらに、IDやパスワードは、複数のWebサイトに対して、共通のIDとパスワードが用いられる場合も多い。この場合、1組のID及びパスワードが不正に悪意のある第三者に取得されてしまった場合、複数のWebサイトに対して連続して不正なアクセスが実行されてしまう場合も散見される。
このような場合、ある一つのWebサイトへの不正アクセスが検出された場合に、その情報を他のWebサイトの事業者に提供することが、上述した共通のIDとパスワードを利用することによる連続した不正アクセスを防ぐために効果的であると考えられる。
しかし、そのような仕組みは未だ十分には実現されていない。例えば、そのような不正アクセスに関する情報としてどのような情報が有効か確定したルールが構築されていない。また、不正アクセスであるとの認定手法が世の中において十分に確立されたているとは言い難い。さらに、例えばあるIPアドレスが、不正アクセスに用いられたとしても、当該IPアドレスが常に不正アクセスに用いられるわけではない。
本発明は、かかる課題に鑑みなされたものであり、その目的は、不正アクセスであるとの可能性がある情報をブラックリストとしてデータベース化し、同様の不正アクセスを効率的に検出することが可能なシステムを実現することである。さらに、そのシステムを実現するための関連する装置、方法、コンピュータプログラムを提供することも本発明の目的である。
(1)本発明は、上記課題を解決するために、ユーザに対して所定のサービスを提供するサービス提供システムにおいて、前記ユーザに対して所定のサービスを提供するサーバ部と、前記ユーザが正規のユーザか否かを判断する認証サーバ部と、を備え、前記サーバ部は、前記ユーザの情報を前記認証サーバ部に提供し、前記認証サーバ部が正規のユーザであると判断した前記ユーザに対して前記所定のサービスの提供を実行するサービス提供手段と、前記ユーザの前記サーバ部に対する動作の情報を、外部の照合装置に送信する送信手段と、を含み、前記認証サーバ部は、前記ユーザの情報を前記サーバ部から受信し、前記ユーザが正規のユーザか否か判断する判断手段と、前記外部の照合装置から、前記ユーザが正規のユーザではない指標を受信する受信手段と、を含み、前記ユーザが正規のユーザではない指標を取得することができることを特徴とするサービス提供システムである。
(2)また、本発明は、(1)記載のサービス提供システムにおいて、前記認証サーバ部は、さらに、前記受信手段が受信した前記指標に基づき、前記ユーザが正規のユーザではない確率が所定の閾値以上であると判断される場合に、前記サーバ部に対して、前記ユーザに対して正規のユーザであるか否か確認する確認処理を実行する指示を出す確認指示手段、を含み、前記サーバ部の前記サービス提供手段は、前記確認処理を実行する指示を受信した場合に、前記ユーザに対して確認処理を実行することを特徴とするサービス提供システムである。
(3)また、本発明は、(1)または(2)記載のサービス提供システムにおいて、前記サービス提供手段が、前記確認処理の結果、前記ユーザが正規のユーザではないと判断した場合に、前記送信手段は、前記外部の照合装置に対して、前記ユーザが正規のユーザではない旨を送信することを特徴とするサービス提供システムである。
(4)本発明は、上記課題を解決するために、ユーザの動作の情報に基づき、前記ユーザが正規のユーザではない指標を求める照合装置において、外部のサービス提供システムから、ユーザの動作の情報を受信する通信手段と、正規のユーザではないと判断された前記ユーザの動作の情報を記録したブラックリストデータベースと、前記受信手段が受信した前記ユーザの動作の情報と、前記ブラックリストデータベース中のデータを比較し、その近似の程度から、前記ユーザが正規のユーザではない指標を算出して送信するブラックリスト指標算出手段と、を含むことを特徴とする照合装置である。
(5)また、本発明は、上記(4)記載の照合装置において、前記通信手段は、前記ユーザが正規のユーザではない指標を外部に送信することを特徴とする照合装置である。
(6)また、本発明は、上記(4)または(5)記載の照合装置において、前記正規のユーザでない指標は、正規のユーザではない確率であることを特徴とする照合装置である。
(7)また、本発明は、上記(4)から(6)のいずれか1項に記載の照合装置において、正規の前記ユーザの動作の情報を記録したホワイトリストデータベースと、前記受信手段が受信した前記ユーザの動作の情報が、前記ホワイトリストデータベース中のレコードに該当しないと判断された場合に、前記ブラックリストデータベースは、前記受信した前記ユーザの動作の情報を、前記ブラックリストデータベースに登録することを特徴とする照合装置である。
(8)また、本発明は、上記(4)から(7)のいずれか1項に記載の照合装置において、前記受信手段が、前記ユーザが正規のユーザではない旨を受信した場合に、前記ブラックリストデータベースは、前記ブラックリストデータベース中の前記ユーザの動作の情報に、ブラック確定フラグを立たせることを特徴とする照合装置である。
(9)また、本発明は、上記(8)記載の照合装置において、前記ブラックリスト指標算出手段は、前記受信手段が受信した前記ユーザの動作の情報と、前記ブラックリスト中のレコードとを比較し、その近似の程度の高い前記ブラックリスト中のレコードの前記ブラック確定フラグが立っている場合は、前記ユーザが正規のユーザでない指標をより高く算出して送信することを特徴とする照合装置である。
(10)本発明は、上記課題を解決するために、ユーザに対して所定のサービスを提供するサーバ部と、前記ユーザが正規のユーザか否かを判断する認証サーバ部と、を備えたサービス提供システムを用いて、前記ユーザに対して所定のサービスを提供するサービス提供方法において、前記サーバ部が、前記ユーザの情報を前記認証サーバ部に提供し、前記認証サーバ部が正規のユーザであると判断した前記ユーザに対して前記所定のサービスの提供を実行するサービス提供ステップと、前記サーバ部が、前記ユーザの前記サーバ部に対する動作の情報を、外部の照合装置に送信する送信ステップと、前記認証サーバ部が、前記ユーザの情報を前記サーバ部から受信し、前記ユーザが正規のユーザか否か判断する判断ステップと、前記認証サーバ部が、前記外部の照合装置から、前記ユーザが正規のユーザではない指標を受信する受信ステップと、を含むサービス提供方法である。
(11)本発明は、上記課題を解決するために、ユーザの動作の情報に基づき、前記ユーザが正規のユーザではない指標を求める照合方法において、前記ユーザの動作の情報を受信する通信ステップと、正規のユーザではないと判断された前記ユーザの動作の情報をブラックリストデータベースに記録するステップと、前記通信ステップにおいて受信した前記ユーザの動作の情報と、前記ブラックリストデータベース中のデータを比較し、その近似の程度から、前記ユーザが正規のユーザではない指標を算出して送信するブラックリスト指標算出ステップと、を含むことを特徴とする照合方法である。
(12)本発明は、上記課題を解決するために、コンピュータを、ユーザに対して所定のサービスを提供するサーバ部と、前記ユーザが正規のユーザか否かを判断する認証サーバ部と、を備えたサービス提供システムとして動作させるコンピュータプログラムにおいて、前記コンピュータに、前記サーバ部として、前記ユーザの情報を前記認証サーバ部に提供し、前記認証サーバ部が正規のユーザであると判断した前記ユーザに対して前記所定のサービスの提供を実行するサービス提供手順と、前記サーバ部として、前記ユーザの前記サーバ部に対する動作の情報を、外部の照合装置に送信する送信手順と、前記認証サーバ部として、前記ユーザの情報を前記サーバ部から受信し、前記ユーザが正規のユーザか否か判断する判断手順と、前記認証サーバ部として、前記外部の照合装置から、前記ユーザが正規のユーザではない指標を受信する受信手順と、を実行させることを特徴とするコンピュータプログラムである。
(13)本発明は、上記課題を解決するために、コンピュータを、ユーザの動作の情報に基づき、前記ユーザが正規のユーザではない指標を求める照合装置として動作させるコンピュータプログラムにおいて、前記コンピュータに、前記ユーザの動作の情報を受信する通信手順と、正規のユーザではないと判断された前記ユーザの動作の情報をブラックリストデータベースに記録する手順と、前記通信手順において受信した前記ユーザの動作の情報と、前記ブラックリストデータベース中のデータを比較し、その近似の程度から、前記ユーザが正規のユーザではない指標を算出して送信するブラックリスト指標算出手順と、を実行させることを特徴とするコンピュータプログラムである。
このように、本発明によれば、ブラックリストデータベースを構築し、これに基づき、正規のユーザではない指標を提供しているので、正規のユーザではないと判断されたユーザによるアクセスをより効率的に検出することが可能となる。
本実施形態に係るWebサイト10の構成の概要を説明する説明図である。 本実施形態に係るホワイトリストデータベースの記録例と、ブラックリストデータベースの記録例を示す説明図である。 本実施形態におけるWebサイト10によるサービスの提供が行われる場合の処理の流れを示す全体構成図である。 照合サーバ34の構成ブロック図である。 本実施形態に係るシステム全体の動作の流れを示すタイムチャートである。 照合サーバ34の動作を表すフローチャートである。 照合サーバ34の動作を表すフローチャートである。
以下、本発明の好適な実施形態を図面に基づき説明する。
第1.基本的考え方
図1には、所定のサービス(例えばショッピングモール)をインターネット等のネットワークを介して提供するためのWebサイトの構成の概要を説明する説明図である。同図は、いわゆるサイトマップと呼ばれる図の1種である。
以下、図1に示すWebサイト10が、例えばショッピングモールを構成するものとして説明を行う。Webサイト10は、まずTopページ12を備えており、そのTopページからログインページ14、商品ページ16、会社概要ページ18にリンクが張られており、移動することができる。ログインページ14において、ユーザがそのIDとパスワードとを用いてログインをした後は、会員情報ページ20、購入ページ22、送金・ポイント交換ページ24に移動することができる。
このようなWebサイト10において、ユーザは、例えば下記のような動作を実行する。
(1)ユーザの動作及びホワイトリスト、ブラックリスト
ショッピングモールを利用しようとするユーザは、まずTopページ12にアクセスし、次に、商品ページ16に移動して購入したい商品を閲覧する。購入したい商品が決定したユーザはログインページ14に移動してIDとパスワードとを入力してログインする。その後、ユーザは購入ページ22に移動して、商品購入手続きを実行する。ユーザは商品を購入した後、送金・ポイント交換ページ24に移動し、これまでにたまったポイントと、そのポイントで交換可能な商品を確認してから、ログオフして、Webサイト10の利用を終える。
本実施形態においては、ユーザがこのような動作を実行した場合に、Webサイト10は、このユーザの動作を記録しておき、ホワイトリストデータベースを構築している。記録されるユーザの動作としては、ページ遷移(ページ間の移動)の他、ユーザが用いているブラウザから取得できるユーザのIPアドレスや、使用している端末の種類、使用しているOS、等が挙げられる。これらの動作を記録し、ホワイトリストデータベースを構築することにより、その「ユーザらしさ」をデータベース化することができる。
このようなホワイトリストデータベースによれば、そのユーザの動作を、これまでのそのユーザの動作と比較照合することができ、ユーザがこれまでと同様の動作を実行しているのか、それとも、これまでにはない動作をしているか、を知ることが可能である。
そして、Webサイト10内におけるユーザのページ遷移等において、これまでのそのユーザとは異なる動作が検出された場合は、それに基づきホワイトリストデータベースではなく、いわゆるブラックリストデータベースに登録することもできる。ブラックリストデータベースは、正規のユーザではない恐れのある動作の情報を記録するデータベースである。その結果、ユーザに対して追加認証(リスクベース認証:Risk Based Authentication)を実行する等の対処をとることも可能である。そのユーザになりすました悪意のある第三者によるアクセスをブロックできる場合もある。
この場合、悪意のある第三者とは、人間が自らキーボード等を用いてアクセスを実行している場合もあれば、また、コンピュータ等が機械的にそのユーザになりすましてアクセスを実行している場合もある。
(2)ブラックリスト
本実施形態において特徴的なことは、正規のユーザらしさをホワイトリストデータベースとして構築したことに加えて、このホワイトリストデータベースから外れた動作をブラックリストデータベースとしてデータベース化したことである。このようにデータベース化することによって、不正な「なりすまし」の動作の情報を保存、蓄積及び比較することができ、悪意のある第三者によるなりすまし等の不正なアクセスをより効率的に検知し、さらに排除できる可能性を向上させることができる。
ここで、「外れた」とは、基本的には、その動作が、既存のホワイトリストデータベースに登録されているレコードとは近似しないデータを備えていることを言う。また、単にデータが近似している/近似していないだけでなく、特定のIPアドレスからのアクセスが1日100回以上発生した場合等を「外れた」とみなす場合に含めてもよい。
(3)ホワイトリストとブラックリストの内容
本実施形態で構築するホワイトリストデータベースと、ブラックリストデータベースの内容の例を説明する。両者は記録する内容としてはほぼ同様である。ただし、ブラックリストデータベースには、後述するように、ホワイトリストデータベースにはないブラック確定フラグが各レコードに設けられている。次に述べる図2では、ブラック確定フラグについては省略して示されていない。ブラック確定フラグに関しては、後にその動作や機能を詳述する。
図2には、正規のユーザの動作の情報を記録したホワイトリストデータベースの記録例と、その正規のユーザになりすました悪意のある第三者の動作の情報を記録したブラックリストデータベースの記録例を示す説明図が示されている。
同図に示すように、ホワイトリストデータベース(およびブラックリストデータベース)に記録される内容は、5種類に分けられる。第1の種類の情報は、ユーザ情報であり、主としてIDとパスワードである。このユーザ情報は、動作の主体であるユーザ30を特定する情報である。
このユーザ情報は、ホワイトリストデータベースにもブラックリストデータベースにも記録されるが、ともにハッシュ化されたID、および、ハッシュ化されたパスワードが記録される。これは、データの量をコンパクトにして比較演算等を容易にするためであり、また、個人を完全に特定されてしまうことを防止し、個人情報の漏洩の可能性を減少させるためである。
第2の種類の情報は、端末情報であり、ユーザがWebサイト10にアクセスした際に用いた端末の情報であり、用いられる端末の種類とOSの種類等が記録される。また、使用言語に関する情報も記録される。第3の種類の情報は、ユーザが使用しているブラウザの情報である。このブラウザの情報も、使用する端末毎に記録される。使用するブラウザが複数種類ある場合も、複数のブラウザの情報が記録される。
第4の種類の情報は、ユーザのIPアドレスである。このIPアドレスからユーザの位置を知ることができる。第5の種類の情報は、ページ遷移である。この情報は、図2に示すように、リファラーURLや、Webサイト10上でどのようなページを閲覧したかを示す情報である。例えば、図2の例では、ホワイトリストデータベースの正規のユーザは、ログインした後、購入履歴ページで購入履歴を確認した後、ポイント確認ページを閲覧して利用可能なポイントを確認している。なお、ブラックリストデータベースの正規のユーザになりすました悪意のある第三者は、ログイン後、すぐにポイント交換ページに行き、ポイント交換をしようとしている。このように、Webサイト10で閲覧するページが、正規のユーザとなりすました悪意のある第三者とでは大きく異なることが、経験的に知られている。
さらに、ページ遷移の情報においては、Webサイト10に滞在した時間も記録される。一般に正規のユーザと比較して、悪意のある第三者はWebサイト10に滞在する時間が短いことが知られている。このような時間の情報としては、さらに、閲覧した各ページにおいて滞在した時間も記録しておくことが好ましい。
なお、悪意のある第三者としては、人間である場合もあるし、正規のユーザになりすました機械(コンピュータ)である場合もある。このようなコンピュータが正規のユーザになりすましている場合は、Webサイト10全体の滞在時間も、各ページに滞在する時間も非常に短い場合が多く、滞在時間に基づいて人間と区別することができる場合もある。また、文字入力のスピードが異常に早いことでも人間と区別することが可能な場合もある。
図2に示す例では、理解を容易にするために、端末情報や、ブラウザの情報等において、正規のユーザと悪意のある第三者の動作が大きく異なる例を示したが、いずれか1種類の情報が大きく異なる場合においてもホワイトリストデータベースから「外れ」ていると判断してもよい。なお、このような判断基準は、さまざまな基準を用いてよい。このようにして、Webサイト10にアクセスしてきたユーザ(になりすました第三者)の動作と、ホワイトリストデータベースに登録された動作の情報と、を比較して、ホワイトリストデータベースに登録されているデータと比べて「外れている」と判断された場合は、その動作の上記情報は、ブラックリストデータベースに登録される。
ブラックリストデータベースが構築されている場合、ユーザ30の動作の情報をそのブラックリストデータベース中の情報と比較して近似していれば、効率的に、当該ユーザが悪意のある第三者によるなりすましの確率が高いと判断することができる。
ここで説明した記録内容は、一例であり、もっと多種多様な種類の情報を記録してもよい。また、ここで説明した記録内容は、標準的な例を示したものであり、より少ない種類の情報を用いてホワイトリストデータベースやブラックリストデータベースを構成してもよい。
第2.本実施形態の具体的な構成
(1)本実施形態におけるシステムの全体構成
図3には、本実施形態におけるWebサイト10によるサービスの提供が行われる処理の流れを示す全体構成図が示されている。同図に示すように、ユーザ30と、事業者システム32と、照合サーバ34と、を備える構成上で本サービスの提供が行われる。これらの各構成は、インターネット等の通信ネットワークを介して相互に接続されており、情報や指示、メッセージ、後述するなりすまし確率等を相互に(または一方向で)送受信することができる。
(2)ユーザ
ユーザ30は、Webサイト10(例えばショッピングモール)にアクセスするユーザ30であり、パソコンや携帯端末からWebサイト10にアクセスする。ここでは、ユーザ30が使用するパソコンや携帯端末を便宜上「ユーザ」30と呼ぶ。
ユーザ30は、Webサイト10にアクセスすると、ログインページにおいてIDとパスワードとを用いてログインを試みる。この動作は、図3中(1)で示されている。
(3)事業者システム
この事業者システム32は、Webサイト10を実現しているシステムであり、例えばショッピングモールを運営する事業者のシステムである。事業者システム32は、Webサーバ32aと、認証サーバ32bと、から構成されている。
事業者システム32は、請求の範囲のサービス提供システムの好適な一例に相当する。
(3−1)Webサーバ
Webサーバ32aは、Webサイト10を提供するWebサーバである。当該Webサイト10は、その動作は例えばHTML(Hyper Text Markup Language)によって記述されている。Webサーバ32aは、請求の範囲のサーバ部の好適な一例に相当する。
本実施形態におけるWebサーバ32aは、大別して2種類の機能(手段)を備えている。それぞれが、それらの機能を記述するプログラムと、そのプログラムを実行するWebサーバ32aのCPU(又はプロセッサ)と、から各機能が実現されている。
サービス提供機能
まず、Webサーバ32aは、ユーザ30にWebサイトのサービスを提供するためのサービス提供機能を備えている。この機能は、通常のWebサイトを提供する機能であり、Webサーバ32aのCPU等がWebサーバプログラムを実行することによって実現されている。そのWebサイト10の具体的な構成・機能は、例えばHTML等で記述されていてよい。また、このサービス提供機能は、ユーザ30が入力したIDとパスワードとを認証サーバ32bに送信する機能も含んでいる(図3中、(2)で示される)。
また、このサービス提供機能は、ユーザ30に対して追加認証の処理を実行した場合に、次に述べる送信機能に対して、その結果の送信を指示する。
このサービス提供機能は、請求の範囲のサービス提供手段の好適な一例に相当する。
送信機能
また、本実施形態におけるWebサーバ32aは、ユーザ30がWebサイト10に対して実行した動作の情報を、外部の照合サーバ34に送信する送信機能を備えている。この送信機能による送信の動作は、図3中(3)で示されている。
この送信機能は、例えば、Webサイト10の構成・機能を記述する上記HTML中に所定のプログラムを記述しておくことによって実現することが好ましい。また、例えば、送信の機能を記述したJavaScript(登録商標)を、このHTMLファイル中に埋め込んで、送信機能を実現することも好適である。
また、送信機能は、サービス提供機能から、追加認証を実行した結果の送信を指示された場合、追加認証の結果を、外部の照合サーバ34に送信する。特に、サービス提供機能が追加認証の結果、ユーザ30が正規のユーザではないと判断した場合に、照合サーバ34に対して、ユーザが正規のユーザではない旨を送信する。
この送信機能は、請求の範囲の送信手段の好適な一例に相当する。
このように、Webサーバ32aは、ユーザ30へのサービスを提供することや、ユーザの認証に関する処理を行うサービス提供機能(サービス提供手段)と、照合サーバ34に対して所定の情報やメッセージを送信する送信機能(送信手段)と、を備えている。
したがって、外部の照合サーバ34は、Webサーバ32aが送信機能を用いて送信してきたユーザ30の動作の情報に基づいてホワイトリストデータベースや、ブラックリストデータベースを構築することができる。
(3−2)認証サーバ
認証サーバ32bは、ユーザ30の認証動作や、認証動作の実行を判断する。この認証サーバ32bは、請求の範囲の認証サーバ部の好適な一例に相当する。
本実施形態における認証サーバ32bは、大別して3種類の機能(手段)を備えている。それぞれが、それらの機能を記述するプログラムと、そのプログラムを実行する認証サーバ32bのCPU(又はプロセッサ)と、から各機能が実現されている。
判断機能
まず、認証サーバ32bは、Webサーバ32aから送信されてきたユーザ30のIDとパスワードに基づき、そのユーザ30が正規のユーザであるか否かを判断し、その判断結果(認証結果)をWebサーバ32aに返す機能(判断手段)を備えている。この動作は、図3中、(6)で表されている。この判断機能は、判断処理を実行するプログラムと、このプログラムを実行する認証サーバ32bのCPU(又はプロセッサ)とから構成されている。そして、Webサーバ32aは、認証サーバ32bの認証結果に基づき、ユーザ30のログインを認める、又は、拒否する等の動作を実行する。
この判断機能は、請求の範囲の判断手段の好適な一例に相当する。
さらに、認証サーバ32bの判断機能は、Webサーバ32aから受信した上記IDをハッシュ化し、このハッシュ化IDを、外部の照合サーバ34に送信する機能を含んでいる。この動作は、図3中、(4)で示される。この結果、照合サーバ34は、当該IDと、Webサーバ32aから提供されたユーザの動作情報と、に基づいて、正規のユーザの動作の情報を記録したホワイトリストデータベース等を構築することができる。
受信機能
また、認証サーバ32bは、外部の照合サーバ34から、ユーザの動作情報に基づく、ユーザ30が悪意のある第三者によるなりすましである確率(「なりすまし確率」と称する)を適宜受信する機能を備えている。この受信の動作は、図3中、(5)で示されている。この受信機能は、照合サーバ34との通信のための通信インターフェースと、通信インターフェースを制御するためのプログラムと、そのプログラムを実行する認証サーバ32bのPCU(又はプロセッサ)とから実現されている。
ここで、「なりすまし確率」とは、要するに、ユーザ30が正規のユーザではない確率、すなわち正規のユーザになりすました悪意のある第三者や、正規のユーザになりすました機械(コンピュータ、ロボット等)である確率である。
なお、本実施形態では、「確率」を用いているが、確率を示すような指標であれば同様に利用することができる。例えば、確率(0〜1の実数)の代わりに0〜255の数値で正規のユーザではない程度を示してもよい。また、正規のユーザではない程度を「大」「中」「小」で表すような指標を利用してもよい。その他、正規のユーザではない程度を示す指標であればどのような指標でも利用することができる。
確認指示機能
認証サーバ32bは、受信機能が受信したなりすまし確率に基づいて、そのユーザ30に追加認証が必要かどうかを判断する。そして、追加認証が必要であると判断される場合は、認証サーバ32bは、追加認証の指示をWebサーバ32aに送信する確認指示機能を備えている。この追加認証の指示は、図3中、(7)で示されている。この確認指示機能も、なりすまし確率と所定の閾値とを比較し、塚認証が必要か否かを判断するプログラムと、そのプログラムを実行するCPU等と、から構成される。
また、この確認指示機能は、請求の範囲の確認指示手段の好適な一例に相当する。そして、追加認証の指示は、請求の範囲の確認処理を実行する指示の好適な一例に相当する。
Webサーバ32aのサービス提供機能は、追加認証の指示を受信した場合、ユーザ30に対して追加認証を実行する。追加認証は、種々の方法を利用することができる。正規のユーザ30の携帯端末に、「現在貴方のIDを用いてWebサイト10へのアクセスが行われています。このアクセスが貴方によるものでない場合は、不正のボタンを押下(又はタッチ)してください」等のメッセージを送信する。これに対して不正のボタンが押下(又はタッチ)された場合は、現在Webサイト10にアクセスしているのは悪意のある第三者によるなりすましであると判断することができ、アクセスを切断することができる。
(3−3)照合サーバ
照合サーバ34は、Webサーバ32aが送信してくるユーザ30の動作の情報を受信し、記録することによって、ホワイトリストデータベースを構築する。本実施形態において特徴的なことは、ユーザ30の動作の情報が、ホワイトリストデータベース中のレコードとは近似していない場合(近似するレコードがない場合)に、悪意のある第三者によるなりすましの可能性があると判断し、その動作の情報をブラックリストデータベースに登録することである。
照合サーバ34は、これらホワイトリストデータベースと、ブラックリストデータベースを用いて、Webサーバ32aが送信してくるユーザ30の動作の情報(図3中(3))に基づき、そのユーザ30が正規のユーザではない確率を算出し、認証サーバ32bに送信する(図3中(5)で示される)。照合サーバ34は、請求の範囲の照合装置の好適な一例に相当する。
(3−3a)照合サーバ34の構成
照合サーバ34の構成ブロック図が図4に示されている。照合サーバ34は、通信手段34aと、ホワイトリストデータベース34bと、ブラックリストデータベース34cと、確率算出手段34dと、を備えている。
通信手段
通信手段34aは、事業者システム32との間で情報や指示の送受信を行う手段であり、インターネット等の通信ネットワークを介して、図3で示すように、Webサーバ32aが送信してくるユーザ30の動作の情報を受信し(図3の(3))、図4における他の手段、ホワイトリストデータベース34bと、ブラックリストデータベース34cと、確率算出手段34dと、に受信した情報を提供する。
通信手段は34aは、請求の範囲の通信手段の好適な一例に相当する。
また、通信手段34aは、確率算出手段34dが算出したなりすまし確率を、認証サーバ32bに送信する(図3の(5))。さらに、通信手段34aは、認証サーバ32bから当該ユーザ30に対する追加認証の結果を受信する(図3の(4))。
なお、この通信手段34aは、通信ネットワークとの通信インターフェースと、照合サーバ34中のCPUが実行する所定の通信プログラムと、から構成される。CPUは、この通信プログラムを実行することによって、通信インターフェースを制御することによって、通信手段34aを実現している。
ホワイトリストデータベース
ホワイトリストデータベース34bは、正規のユーザ30の動作の情報を記録したデータベースであり、例えば、正規のユーザ30の1回〜1000回程度のアクセスに基づき、1〜1000程度の動作の情報(レコード)を記録するデータベースである。このホワイトリストデータベース34bは、具体的には、ハードディスク等の記憶手段と、通信手段34aが受信したユーザ30の動作の情報を記憶手段に記録するプログラムと、そのプログラムを実行する(照合サーバ34内の)CPU等とから構成される。この結果、ホワイトリストデータベース34bには、図2で示すような正規のユーザ30の動作の種々の情報が記録されていく。この記録は1人のユーザ30毎に1〜1000アクセス程度の情報(レコード)が記憶される。例えば1人当たり10〜30レコード程度が好ましい。本実施形態では、1人当たり最新の20レコードが記憶されている例を説明するが、何個記録してもよい。レコードとは、原則として、ユーザ30がWebサイト10にアクセスを開始してから、ログオフするまでの一連の動作の情報であり、図2で説明したように、使用したブラウザの情報等も含むデータである。しかし、ユーザ30の動作それぞれをレコードとして記録してもよい。ブラックリストデータベース34c中のレコードも同様の概念である。
ホワイトリストデータベース34bは、ユーザ30の動作の情報をホワイトリストデータベース34b中の該当するユーザ30の既存の情報と比較し、両者が近似しないことに基づき「ユーザ30の動作に該当しない」と判断される場合は、これをブラックリストデータベース34cに送り、ブラックリストデータベース34cに記憶させる。この判断も、上記プログラムが実行する。なお、近似する/近似しないの判断は、必ずしもアクセス開始からアクセス終了までの一連の動作で比較しなくてもよい。すなわち一部の情報のみで比較し、近似する/近似しないの判断を行ってもよい。すなわち、ユーザ30のアクセスの途中でリアルタイムに判断してもよい。
ブラックリストデータベース
ブラックリストデータベース34cは、Webサーバ32aから送信されてきたユーザ30の動作の情報であって、ホワイトリストデータベース34b中のレコードと近似せず、いわゆる「外れた」情報であった場合に、その動作の情報を記録したデータベースである。
このブラックリストデータベース34cは、具体的には、ハードディスク等の記憶手段と、ホワイトリストデータベース34b(のプログラム)が、ホワイトリストデータベース34b中のレコードと近似しないと判断して、ブラックリストデータベース34cに送ってきた動作の情報を上記ハードディスク等の記憶手段に記録するプログラムと、そのプログラムを実行する(照合サーバ34内の)CPU等とから構成される。
上述したように、照合サーバ34のホワイトリストデータベース34bは、正規のユーザ30の動作の情報を記録している。ホワイトリストデータベース34bは、Webサーバ32aが送信したユーザ30の動作の情報と、ホワイトリストデータベース34b中の情報とを比較し、近似せず、外れていると判断した場合は、その動作の情報をブラックリストデータベース34cに送信する。ブラックリストデータベース34cは、この送信されてきた動作の情報を記憶するデータベースである。
このように、ブラックリストデータベース34cは、ホワイトリストデータベース34bと同様に、ユーザ30の動作の情報を記録するデータベースであるため、その記憶項目は、ホワイトリストデータベース34bとほぼ同様であることは、図2で説明した通りである。ただし、ブラックリストデータベース34cには、ホワイトリストデータベース34bにはない特有のフラグ「ブラック確定フラグ」が各レコードに設けられている。このフラグは、各動作の情報が正規のユーザ30ではない者による動作の情報であるということが確定した場合に「1」となるフラグである。
ここで、ブラック確定フラグが「1」になるとは、請求の範囲において、ブラック確定フラグが立つことの好適な一例に相当する。
ブラックリストデータベース34cに、新たにホワイトリストデータベース34b中の動作の情報とは「外れた」動作の情報が記録された際には、その動作の情報のブラック確定フラグは「0」である。このブラック確定フラグが「0」であるとは、ブラック確定フラグが立っていない状態の一例である。
その後、Webサーバ32aが実行する追加認証処理によって、その動作の情報が、正規のユーザ30による動作ではないことが確定した場合に、当該動作の情報のレコードのブラック確定フラグが「1」に設定される(ブラック確定フラグが立つ)。このブラック確定フラグを「1」に設定する等の動作も、上記プログラムが実行する。また、このブラック確定フラグの値は、確率算出手段34dが実行する確率の計算に利用される。
確率算出手段
確率算出手段34dは、Webサーバ32aが送信してくるユーザ30の動作の情報に基づき、その動作の情報が正規のユーザによるものではない確率であるなりすまし確率を算出して認証サーバ32bに送信する(図3の(5)に相当する)。
確率算出手段34dは、確率算出手段34dが実行する算出動作を記述したプログラムと、このプログラムを実行する照合サーバ34のCPUと、から構成される。
また、確率算出手段34dは、請求の範囲のブラックリスト指標算出手段の好適な一例に相当する。また、なりすまし確率は、請求の範囲の「正規のユーザではない指標」の好適な一例に相当する。
本実施形態では、なりすまし確率と呼ぶ確率を算出しているが、正規のユーザではない程度を表す指標であれば、単なる「高い」「低い」との指標でもよい。また、確率を、0から10の整数で表し、11段階で表してもよい。これらも請求の範囲の指標の好適な一例に相当する。
確率算出手段34dは、まず、Webサーバ32aが送信してくるユーザ30の動作の情報がブラックリストデータベース34cに記載されているレコードに近似しているか否かに基づき、その近似の程度に応じてなりすまし確率を算出する。近似の程度が高ければ、なりすまし確率は高くなり、近似の程度が低ければ、なりすまし確率は低く算出される。このように、近似するレコードとの近似の程度に応じて、そのレコードに該当する確率を算出する数学的手法は、従来から種々知られているので、そのような計算手法を適宜利用すればよい。簡便には、レコード(動作の情報)を構成する種々の要素の差分の2乗値を積算した合計値をポイントとして算出し、かかるポイント値が小さいほど確率が高くなる(1に近づく)ように確率を計算してもよい。
また、この近似しているか否かの判断は、動作の情報が送信されてくる度に実行してよい。すなわち、比較は、一部の要素のみの比較でもよい。例えば、ページ遷移が2回程度の場合でも、ブラックリストデータベース34c中のレコード(ページ遷移が多く記録されている場合もある)と比較してよい。この結果、ユーザ30の動作に対してリアルタイムになりすまし確率を算出することができる。
また、Webサーバ32aが送信してくるユーザ30の動作の情報と最も近似していると判断されたブラックリストデータベース34c中のレコード(群)のブラック確定フラグが「1」であれば、同様の近似の程度でも、なりすまし確定フラグが「0」の場合と比較して、求めるなりすまし確率をより高く補正して算出することも好適である。正規のユーザ30の動作の情報ではないとの判断が確定されているレコードと近似している場合は、正規のユーザ30でない確率が高いと考えられるからである。
本実施形態における確率算出手段34dは、このようにブラックリストデータベース34c中の情報に基づき、ユーザ30のなりすまし確率を算出する。
なお、ブラックリストデータベース34c中にユーザ30の動作の情報と近似するレコードがない場合は、原則として、低い値のなりすまし確率を算出し、送信する。なお、ブラックリストデータベース34c中にユーザ30の動作の情報と近似するレコードがない場合は、当該情報をホワイトリストデータベース34b中のレコードと比較し、近似するレコードの有無およびその近似度に基づき、なりすまし確率を算出してもよい。この場合、当該動作の情報と近似するレコードが、ホワイトリストデータベース34b中に存在する場合は、正規のユーザ30ではない確率(なりすまし確率)は、低く補正して算出される。他方、当該動作の情報と近似するレコードが、ホワイトリストデータベース34b中に存在しない場合は、なりすまし確率はやや高く補正して算出してもよい。この場合、なりすまし確率の算出の対象となった当該動作の情報は、ブラックリストデータベース34cに新たに登録されることになる。
第3.動作
次に、本実施形態におけるシステムの動作の流れを図に基づき説明する。
図5には、図3で示したシステム全体の動作の流れを示すタイムチャートが示されている。なお、図5のタイムチャートにおいて、上から下に向かって時間が経過するものとする。
まず、ユーザ30がWebサイト10に対してアクセスする。すると、ユーザ30がアクセスに利用するブラウザの情報が、Webサイト10を提供するWebサーバ32aに対して送信される。この動作が図5中、ブラウザ情報の送信40として示されている。
次に、事業者システム32中のWebサーバ32aは、送信されてきたブラウザ情報を受信し、これを照合サーバ34に送信する。この動作は、図5中、ブラウザ情報の送信42として示されている。照合サーバ34においては、通信手段34aがこのブラウザ情報を受信し、ホワイトリストデータベース34b等の他の構成に対してブラウザ情報を送信する。
次に、ユーザ30は、ログインページ14に移行し、IDとパスワードとを入力する。これは、図5中、ID・パスワード送信44として示されている。すると、Webサーバ32aは、送信されてきたID・パスワードを受信し、認証するために認証サーバ32bに送信する(図3中(2))。認証サーバ32bは、このIDとパスワードとを利用してユーザ30の認証を行うとと共に、それらをハッシュ化して、ハッシュ化したIDとハッシュ化したパスワードとを、照合サーバ34に送信する。
この送信動作は、図5中、ハッシュ化されたID・パスワードの送信46として示されている。照合サーバ34においては、通信手段34aがこのハッシュ化されたID・パスワード情報を受信し、ホワイトリストデータベース34b等の他の構成に対してハッシュ化されたID・パスワードを送信する。これによって、ホワイトリストデータベース34b、ブラックリストデータベース34c等において、ハッシュ化されたID・パスワードを記録することができる。
本実施形態では、ハッシュ化されたIDとハッシュ化されたパスワードとの送信46(図5参照)は、認証サーバ32bが実行しているが、Webサーバ32aが実行してもよい。
照合サーバ34は、送信されてきたハッシュ化されたIDおよびパスワードと、ブラウザ情報とから、当該ユーザ30が正規のユーザではない「なりすまし確率」を求め、事業者システム32の認証サーバ32bに送信する。なりすまし確率の算出は、確率算出手段34dが実行し、なりすまし確率の送信は、通信手段34aが実行する。この送信は、図5中、なりすまし確率の送信48で示されている。
認証サーバ32bは、送信されてきたなりすまし確率を受信する。そして、このなりすまし確率に基づき、ユーザ30に対して追加認証を実行するか否かを決定する。認証サーバ32bが追加認証を実行することを決定しない場合は、認証が成功裏に完了したことをWebサーバ32aに送信する(図3中(6))。認証が成功したことが伝えられたWebサーバ32aはユーザに対してログイン許可のメッセージを送信する。これは、図5中、ログイン許可50で示されている。
なお、ここでは、認証サーバ32bが、ハッシュ化されていないIDとパスワードと(図3中(2)で示される)に基づく認証を実行し、正規のユーザである認証が成功裏に完了していることを前提としている。もちろん、このIDとパスワードによる認証が失敗すれば、ログインが許可されない。
ログインしたユーザ30は、Webサイト10内で所望のページの閲覧を開始し、適宜閲覧ページの移動を行う。これは図5中、ページ移動52で示されている。このページ移動は、Webサーバ32aに送信されユーザ30は所望のページに移動することが可能である。さらに、Webサーバ32aは、このようなページ移動を含むユーザの動作の情報全般を、照合サーバ34に送信する。これが、図5中、ページ遷移情報の送信54として示されている。ページ遷移情報の送信54と記されているが、ユーザ30の動作の情報の全般を意味する。
照合サーバ34においては、このページ遷移情報(ユーザ30の動作の情報)をホワイトリストデータベース34bに適宜記録する。ホワイトリストデータベース34bと近似していない場合は、ブラックリストデータベース34cに適宜記録する場合もある。ここで、このページ遷移情報(ユーザ30の動作の情報)は、ホワイトリストデータベース34bやブラックリストデータベース34c中のレコードと比較され、近似度が求められる。近似度に基づき、正規のユーザではない確率であるなりすまし確率が算出される。
この算出は、確率算出手段34dによって実行される。なりすまし確率の詳細な算出動作等については、次の図6(および図7)のフローチャートに基づき説明する。算出されたなりすまし確率は、認証サーバ32bに対して送信される。これが図5中、なりすまし確率の送信56として示されている。
認証サーバ32bは、送信されてきたなりすまし確率を受信し、この確率に基づき、追加認証を実行するべきか判断する。例えば、このなりすまし確率と所定の閾値とを比較し、なりすまし確率のほうが小さい場合に、追加認証を実行すると判断してもよい。その判断の結果、なりすまし確率が所定の閾値より小さく、追加認証を実行すべきである判断した場合は、認証サーバ32bは、Webサーバ32aに対して追加認証を実行する指示を送信する。追加認証の指示は、図3では、(7)で示されている。なお、認証サーバ32bが追加認証の実行をしないと判断した場合は、認証サーバ32bは、Webサーバ32aに対して特に指示を行わない(送信しない)。
この追加認証の指示を受信したWebサーバ32aは、ユーザ30に対して追加認証を実行する。この動作は、図5中、追加認証58として示されている。追加認証58は種々の態様で実行することができる。例えば、ユーザ30に対してユーザ30であれば答えられる追加の質問をすることも好適である。また、ユーザ30が所持している携帯端末に所定のメールを送信し、そのメール中の符号・数字をWeb画面上で入力させることも好適である。また、ユーザ30の所持している携帯端末にメールを送信し、「現在このWebサイト10にアクセスしていないのであればメールを返信してください」等のメッセージを送ることも好適である。その他、種々の追加認証58を実行してよい。
このような追加認証58に失敗した(認証処理が正常に完了しなかった)場合、Webサーバ32aは、追加認証に失敗したことを認証サーバ32bに送信する。この送信処理が、図5中、不正確認60で示されている。
認証サーバ32bは、不正確認60を受信した場合、同旨を、照合サーバ34に送信する。これが、図5中、不正確認62として示されている。また、認証サーバ32bは、強制ログオフの指示をWebサーバ32aに送信する。このログオフの指示は、図5中、強制ログオフ64で示されている。Webサーバ32aは、この強制ログオフ64を受信すると、当該ユーザ30を強制的にログオフし、接続を解除する。
なお、ここで、強制ログオフ64の指示は出さないように構成してもよい。この場合、Webサーバ32aが、不正確認60を送信した後、特に外部から指示が無くとも自発的に、ユーザ30をログオフするように構成してもよい。
照合サーバ34は、不正確認62を受信すると、内部のブラックリストデータベース34c中の該当するレコードのブラック確定フラグを「1」に設定する(フラグをたてる)。
ユーザ30が正規のユーザ30である場合
なお、図5においては、追加認証58に失敗し、ユーザ30が正規のユーザではないことが確認された(不正確認60)場合の動作について説明した。しかし、ユーザ30が正規のユーザであって、たまたまいつもとは異なる場所から、異なる携帯端末でアクセスしたかもしれない。この場合は、ユーザ30は正規のユーザであるので、追加認証58は成功(認証処理が正常に完了)するため、図5における不正確認60や不正確認62は送信されない。この場合は、いずれユーザ30がログオフし、Webサーバ32aが、そのログオフを受信した場合に、当該ログオフを照合サーバ34に送信する。照合サーバ34は、そのログオフを受信すると、一連の動作が終了したと判断して、ユーザ30のそれまでの動作の情報をホワイトリストデータベース34b等に1レコードとして記録する。
ホワイトリストデータベース34bや、ブラックリストデータベース34cにおける1レコードとは、原則として、ユーザ30のWebサイト10に対する1セッションの動作の情報であり、アクセスからログインが実行され〜各ページを閲覧して〜ログオフするまでの動作の情報である。但し、ユーザ30のl動作毎に、1レコードとして取り扱ってもよい。
以上、図5のタイムチャートを用いて説明した動作によって、該当するブラックリストデータベース34c中の動作の情報のレコードを、正規のユーザではない者の動作の情報であると明確に認定することができ、今後は、当該レコードの動作の情報に近似した動作の情報が検出された場合は、なりすまし確率を高く算出することができ、正規のユーザではない者のアクセスであることをより正確に認識できることが期待される。
照合サーバ34の動作
次に、照合サーバ34の動作を図6、図7のフローチャートに基づき説明する。このフローチャートにおいては、特に、ホワイトリストデータベース34bと、ブラックリストデータベース34cと、の構築動作と、なりすまし確率の算出の動作と、を中心に説明し、それ以外のデータの送受信等は図3や図5等で既に説明しているのでその詳細な説明は省略する。
また、図6において、BLDBは、ブラックリストデータベースを表し、WLDBは、ホワイトリストデータベースを意味する。
まず、ステップS1において、照合サーバ34の通信手段34aが、アクセスしてきたユーザ30が使用しているブラウザの情報を受信する。受信したブラウザ情報は、ホワイトリストデータベース34b等の記録内容となり得る情報であり、ホワイトリストデータベース34b、ブラックリストデータベース34c等において適宜利用されうる。また、確率算出手段34dにおいても、既存のデータベース中のレコードとの近似の程度(近似度)の算出等に利用される。
ステップS2において、照合サーバ34の通信手段34aが、ハッシュ化されたIDおよびハッシュ化されたパスワードを、受信する。受信したIDおよびパスワードは、照合サーバ34中の他の手段に対して出力され、他の手段(ホワイトリストデータベース34b等)が必要に応じて、適宜この(ハッシュ化された)IDおよびパスワードを利用する。
ステップS3において、受信したIDおよびパスワードで特定されるレコードであって、且つ近似したレコードが、ブラックリストデータベース34cに存在するか否か判定される。この判定はブラックリストデータベース34cが行い、その結果、該当するレコードが存在すれば、ステップS4に移行し、該当するレコードがブラックリストデータベース34c中に存在しない場合は、図7のステップS10に移行する。
ステップS4において、確率算出手段34dは、受信したIDおよびパスワードに該当し、且つ、データが近似しているブラックリストデータベース34c中のレコードに基づき、なりすまし確率を算出する。ここで、近似しているレコードは1個または2個以上存在していてもよい。そして、以下のような算出基準に基づいて確率が算出される。以下のような基準に基づいていれば、どのような算出手法でもよい。
・近似しているその近似度が高いほど(似ているほど)、なりすまし確率もより高く算出される。
・近似しているレコードが多いほど、なりすまし確率もより高く算出される。
・近似しているレコードのブラック確定フラグが「1」である場合には、なりすまし確率もより高く補正されて算出される。
このような算出基準でなりすまし確率が算出される。確率算出手段34dは、算出したなりすまし確率を、通信手段34aに送信する。通信手段34aは、所定のネットワークを介して、事業者システム32の認証サーバ32bに対して、なりすまし確率を送信する。
ステップS4においては、なりすまし確率の送信と並行して、ブラックリストデータベース34cが、当該IDとパスワード、およびブラウザ情報に係る新しいレコードを記録する。
ステップS5において、照合サーバ34の通信手段34aが、ユーザ30の動作情報の受信を行う。ここで、動作情報とは、例えば図5におけるページ遷移情報の送信54等のユーザ30の動作の情報全般である。
通信手段34aは、受信した動作情報を、照合サーバ34中の他の手段に対して出力し、他の手段(ホワイトリストデータベース34b等)が必要に応じて、適宜この動作情報を利用する。
ステップS6において、ブラックリストデータベース34cは、動作情報を、上記ステップS4において作成した新しいレコードに加えていく。また、確率算出手段34dは、受信した動作情報も含めて、なりすまし確率を算出する。そして、通信手段34aがなりすまし確率を認証サーバ32bに対して送信する。
本実施形態において特徴的なことは、ユーザ30の動作に基づき、このようにリアルタイムになりすまし確率を算出し、認証サーバ32bに提供していることである。その結果、そのユーザ30の動作に基づき、迅速に、ユーザ30が正規のユーザであるか否かの判断材料(なりすまし確率)を提供しているので、認証サーバ32bは、追加認証を実行すべきか否かをリアルタイムに判断することができる。その結果、正規のユーザではない者のアクセスを迅速に遮断することができ、不正な行為をより確実に防止することが可能である。
ステップS7においては、通信手段34aが、不正確認(図5中の不正確認62)を受信したか否かが判定される。不正確認を受信した場合は、ステップS9に移行し、受信していない場合は、ステップS8に移行する。
ステップS8においては、通信手段34aが、ログオフを受信したか否かを判定する。このログオフは、ユーザ30が通常どおりの動作を実行し、正規のユーザではないと決定できなかった(確定できなかった)場合であることを意味する。この判定の結果、ログオフが受信された場合は、それまでのユーザ30の動作の情報を、ブラックリストデータベース34cに1レコードとして記録する。ここで記録される動作の情報(1レコード)は、ユーザ30のWebサイト10に対する1セッションの動作の情報であり、アクセスからログインが実行され〜各ページを閲覧して〜ログオフするまでの動作の情報である。このレコードのブラック確定フラグは「0」に設定される。このようにして、照合サーバ34は、1セッションの動作を終了し、再びユーザ30がWebサイト10にアクセスすることを待つことになる。
他方、ステップS8において、通信手段34aが、ログオフを受信していない場合は、当該ユーザ30によるWebサイトへのアクセスが続行されていることになり、再びステップS5に戻って、ユーザ30の動作の情報の受信の処理を続行する。
ステップS9においては、照合サーバ34が不正確認62(図5参照)を受信し、通信手段34aが不正確認62を、照合サーバ34内の他の手段に提供する。この不正確認62の受信によって、当該ユーザ30が正規のユーザ30ではないことが確定したと判断される。そのため、ブラックリストデータベース34cは、ブラックリストデータベース34c中の当該ユーザの動作の情報(レコード)に対してブラック確定フラグを「1」に設定する。このフラグを「1」に設定することによって、再び、当該ユーザ30の動作情報と近似した動作を実行するユーザ30が現れた場合、それに対するなりすまし確率を高く算出することができる。
ステップS9の後は、再び他のユーザ30がWebサイト10にアクセスすることを待つことになる。
図7のステップS10においては、当該ユーザ30の動作の情報に該当するレコードが、ホワイトリストデータベース34b中に記録されているか否か判定される。この判定は、ホワイトリストデータベース34bが実行する。
判定の結果、ユーザ30の動作の情報がホワイトリストデータベース34b中に記録されていない場合、および、ホワイトリストデータベース34b中に記録されているが、当該ユーザ30のレコード数が20個未満である場合は、ユーザ30に関する動作の情報の蓄積が不十分と判断し、ステップS13に移行する。レコード数が20個以上ある場合は、ステップS11に移行する。
本実施形態におけるホワイトリストデータベース34bは、ユーザ30の動作の情報を記録していくが、そのレコードとして最近の20個のデータを記録するように構成している。20個未満の場合は、ステップS13に移行し、ユーザ30の動作の情報の蓄積を行う。
ステップS11においては、ユーザ30に該当するレコードが20個あるので、ユーザ30の動作の情報と、ホワイトリストデータベース34b中の動作の情報とを比較し、近似しているか否かの判定を実行する。その結果、いずれかのレコードと近似していれば、ホワイトリストデータベース34bへの記録を行うために、ステップS13に移行する。
ステップS12においては、ユーザ30の動作の情報が、ホワイトリストデータベース34b中の既存のレコードと近似していなかったので、いわゆる「外れ」のデータであると判断し、ブラックリストデータベース34cへの記録を行う。この処理は、ブラックリストデータベース34cが実行する。この記録に際して、ブラック確定フラグの初期値は「0」に設定してある。
このホワイトリストデータベース34b中の既存のレコードと近似していないことは、請求の範囲において、ホワイトリストデータベース中のレコードに「該当しない」ことの好適な一例に相当する。
また、同一のIPアドレスから1日に数100回のアクセスがあった場合等も、ここでいう「該当しない」の一例に加えてもよい。その他、請求の範囲における「該当しない」場合として、不正のアクセスと推定される場合全般を含めてもよい。
本実施形態において特徴的なことは、ブラックリストデータベース34cを設けて、不正なアクセスをより効率的に判断していることである。このブラックリストデータベース34cの構築のために、ホワイトリストデータベース34bを用いており、その中のレコードから外れている動作の情報の場合に、ブラックリストデータベース34c中に記録するように構成している。本実施形態では、主としてホワイトリストデータベース34bを用いているが、その他の手法で、すなわちホワイトリストデータベース34bを用いることなく、ブラックリストデータベース34cに登録すべき動作の情報を決定してもよい。例えば、短時間に集中して同一IDによるアクセスがあった場合等も、不正アクセスである可能性が高いと判断してブラックリストデータベース34cに登録してもよい。
ステップS12以降の動作は、ブラックリストデータベース34cへの記録であるので、図6におけるステップS5に移行する。ステップS5以降の動作はすでに説明した通りである。
他方、ステップS13以降の処理では、ユーザ30の動作の情報が、ホワイトリストデータベース34bに記録される。この記録の動作は、ホワイトリストデータベース34bが実行する。本実施形態では、所定の1人のユーザ30に対する動作の情報(レコード)の記録数を、20個と設定している。例えば、そのユーザ30の動作の情報(レコード)が20個未満の場合は、そのまま新たに動作の情報を追加で記録していく。しかし、既にそのユーザ30の動作の情報(レコード)が20個記録されている場合は、新しい動作の情報を記憶するとともに、古いレコードを削除していく。このような動作によって、常に最新の動作の情報の20個のレコードのみがホワイトリストデータベース34b中に記録されている。
ステップS14において、通信手段34aが、動作の情報の受信を行う。通信手段34aは、この動作の情報を、照合サーバ34中の他の手段に提供する。
ステップS15において、ホワイトリストデータベース34bが、提供された上記動作の情報を、そのユーザ30の動作の情報としてホワイトリストデータベース34b中に記録していく。
なお、ブラックリストデータベース34cへ記録を行う場合は、なりすまし確率を計算して、認証サーバ32bに送信している(ステップS4等)。
しかし、ステップS15のように、ホワイトリストデータベース34bに記録している場合は、原則として、「0」の値のなりすまし確率を認証サーバ32bに送信する。すなわち、ホワイトリストデータベース34bに記録する場合とは、ユーザ30の動作の情報が、ホワイトリストデータベース34b中の正規のユーザ30と考えられる動作の情報と近似している場合であり、なりすまし確率としては「0」が妥当と考えられるからである。
ただし、ステップ15のように、ホワイトリストデータベース34bに記録する場合でも、既存のホワイトリストデータベース34b中のレコードとの近似度が計算されるので、その近似度に基づき、なりすまし確率を算出してもよい。
ステップS16においては、通信手段34aが、ログオフを受信したか否かが判定される。判定は通信手段34aが実行する。この判定の結果、ログオフが受信された場合は、それまでのユーザ30の動作の情報が、ホワイトリストデータベース34b中に記録される。そして、他のユーザ30がWebサイト10にアクセスすることを待機することになる。
他方、ステップS16において、ログオフが受信されない場合は、ステップS14に移行して、そのユーザ30の動作の情報を受信する動作を続行することになる。
以上述べたように、本実施形態によれば、照合サーバ34は、事業者システム32との間でデータの送受信を行い、内部のホワイトリストデータベース34bや、ブラックリストデータベース34cを構築する。さらに、照合サーバ34は、その内部の確率算出手段34dが、原則として、ブラックリストデータベース34cに基づき、なりすまし確率を算出し、認証サーバ32bに送信する。
また、本実施形態においては、事業者システム32が1個の場合を説明したが、事業者システム32が複数個あってもよい。この場合は、その複数の事業者システム32が、照合サーバ34を共用することができる。
効果
以上のような動作によって、本実施形態によれば、ホワイトリストデータベース34bだけでなく、正規のユーザ30ではない可能性のあるユーザ30の動作の情報を記録したブラックリストデータベース34cをも構築することができる。
さらに、照合サーバ34を、複数の事業者システム32から共用して利用すれば、ブラックリストデータベース34cの共用を図ることができる。その結果、ある事業者のWebサイト10において正規のユーザ30の動作の情報ではないとしてブラックリストデータベース34cに記録された情報は、他の事業者からも利用することができ、悪意のある第三者の不正なアクセスを未然に防止できる可能性を向上させることができる。
特に、近年では、悪意のある第三者が入手した一組のIDとパスワードを用いて、複数のWebサイトへの不正アクセスが連続して行われる例が数多くみられる。このような連続した不正アクセスに対して、本実施形態における照合サーバ34は特に有用な対抗手段となり得る。また、本実施形態では、単にユーザ30のIDだけではなく、ユーザ30の動作の情報を記録してブラックリストデータベース34c、ホワイトリストデータベース34bを構築しているので、より効率的に、悪意のある第三者によるアクセスを検出することができる。また、動作の情報を記録しているので、ユーザ30の動作毎にリアルタイムになりすまし確率を求めることもでき、より迅速に悪意のある第三者によるアクセスを検出できることが期待される。
第4.変形例
(1)上述した実施形態では、確率算出手段34dは、正規のユーザではない確率を算出した。この確率値は0〜1の実数値である。しかし、「確率」の代わりに、正規のユーザではない程度を示す指標を利用することも好適である。上記確率も、当該指標の好適な一例であるが、他の指標を用いてもよい。例えば、このような指標として、ブラックリストデータベース34c中のデータとの近似度を採用してもよい。この場合、近似の程度が高ければ高いほど、正規のユーザではない程度も高まると考えられる。そこで、このような近似度を指標として用いることも好適である。その他、正規のユーザではない程度を示す指標であれば、どのような指標を算出して利用してもよい。
(2)上述した実施形態では、照合サーバ34が、Webサーバ32aとは離隔した場所に位置する例を説明した。しかし、照合サーバ34は、Webサーバ32aや認証サーバ32bから接続できる場所であればどこに位置してもよく、Webサーバ32aと同様の位置に配置されていてもよい。例えば、事業者システム32内に位置してもよい。
また、上述した実施形態では、認証サーバ32bは、Webサーバ32aと同一サイトに位置する例を説明した。しかし、認証サーバ32bは、Webサーバ32aや照合サーバ34から接続できる場所であればどこに位置してもよく、Webサーバ32aから離隔した位置に配置されていてもよい。例えば、事業者システム32の外部に位置してもよい。
(3)上述した実施形態では、ホワイトリストデータベース34b中の同一のユーザの動作の情報(レコード)の記録数は例えば20個と設定されているが、より少ない数でもよいし、また、多くてもかまわない。また、状況に応じて登録数を動的に調整するように構成してもよい。
(4)上述した実施形態では、照合サーバ34は、なりすまし確率を事業者システム32に送信しているが、このなりすまし確率とともに、なりすまし確率の計算の主な要因となった最も近似しているブラックリストデータベース34c中の情報も送信するように構成してもよい。
このように構成すれば、事業者システム32側において、どのような不正のアクセスがあったのかを知ることができ、セキュリティの確保に資することができる場合もある。但し、たとえ不正のアクセスのデータであっても、国によっては個人情報保護の対象になる場合や、その他の保護の対象になる場合もあるので、そのような場合には該当する情報の提供は慎重にするべきである。
(5)上述した実施形態では、ユーザ30の動作の情報がホワイトリストデータベース34bに記録される場合は、なりすまし確率として「0」を送信しているが、ホワイトリストデータベース34b中のレコードとの近似度に応じてなりすまし確率を算出して、「0」以外の値のなりすまし確率を送信してもよい。
(6)上述した実施形態では、ブラックリストデータベース34c中のレコード数は制限を設けていないが、比較照合の演算速度等を考慮して、数に制限を設けてもよい。その場合は、例えば、古いレコードから削除していく等の処理を行ってもよい。
(7)上述した実施形態では、ホワイトリストデータベース34b中のデータは実際のアクセスに基づき記録していったが、人為的に予め典型的な正規のデータを記録しておいてもよい。また、ブラックリストデータベース34c中に、予め判明している不正なアクセスの例を人為的に記憶させておいてもよい。
(8)上述した実施形態では、ホワイトリストデータベース34b中のデータは、新しいアクセスの度に更新され、古いデータは削除されていくが、人為的に固定したレコードを指定しておいてもよい。アクセスの頻度が低いユーザを考慮したものである。
(9)また、ホワイトリストデータベース34b、ブラックリストデータベース34cのレコードは人為的な手段、または他の手段で適宜チューニングを施してもよく、また、人の手によって、あまり重要でないレコードを削除してもよい。種々の人為的な作業を施してもよい。
(10)上記実施形態では、ハッシュ化されたIDと、ハッシュ化されたパスワードとが、ホワイトリストデータベース34b、ブラックリストデータベース34cに記録されるが、ハッシュ化されないデータを用いてもよく、また所定の暗号化が施されたIDとパスワードを利用してもよい。
以上、本発明の実施形態について詳細に説明したが、前述した実施形態において、プログラムと、そのプログラムを実行するCPU等とから種々の機能・手段が実現されている。ここで、上述した種々のプログラムは、請求の範囲のコンピュータプログラムの好適な一例に相当する。
また、本発明の実施形態について詳細に説明したが、前述した実施形態は、本発明を実施するにあたっての具体例を示したに過ぎない。本発明の技術的範囲は、前記実施形態に限定されるものではない。本発明は、その趣旨を逸脱しない範囲において種々の変更が可能であり、それらも本発明の技術的範囲に含まれる。
10 Webサイト
12 Topページ
14 ログインページ
16 商品ページ
18 会社概要ページ
20 会員情報ページ
22 購入ページ
24 送金・ポイント交換ページ
30 ユーザ
32 事業者システム
32a Webサーバ
32b 認証サーバ
34 照合サーバ
34a 通信手段
34b ホワイトリストデータベース
34c ブラックリストデータベース
34d 確率算出手段
40 ブラウザ情報の送信
42 ブラウザ情報の送信
44 ID・パスワードの送信
46 ハッシュ化されたID・パスワードの送信
48 なりすまし確率の送信
50 ログイン許可の送信
52 ページ移動の送信
54 ページ遷移情報の送信
56 なりすまし確率の送信
58 追加認証
60 不正確認
62 不正確認
64 強制ログオフ
BLDB ブラックリストデータベース
WLDB ホワイトリストデータベース

Claims (7)

  1. ユーザの動作の情報に基づき、前記ユーザが正規のユーザではない指標を求める照合装置において、
    外部のサービス提供システムから、ユーザの動作の情報を受信する通信手段と、
    正規のユーザではないと判断された前記ユーザの動作の情報を記録したブラックリストデータベースと、
    前記通信手段が受信した前記ユーザの動作の情報と、前記ブラックリストデータベース中のデータを比較し、その近似の程度から、前記ユーザが正規のユーザではない指標を算出して送信するブラックリスト指標算出手段と、
    正規の前記ユーザの動作の情報を記録したホワイトリストデータベースと、を含み、
    前記通信手段が受信した前記ユーザの動作の情報が、前記ホワイトリストデータベース中のレコードに該当しないと判断された場合に、前記ブラックリストデータベースは、前記受信した前記ユーザの動作の情報を、前記ブラックリストデータベースに登録する
    ことを特徴とする照合装置。
  2. 請求項1記載の照合装置において、
    前記通信手段は、前記ユーザが正規のユーザではない指標を外部に送信することを特徴とする照合装置。
  3. 請求項1または2記載の照合装置において、
    前記正規のユーザでない指標は、正規のユーザではない確率であることを特徴とする照合装置。
  4. 請求項1からのいずれか1項に記載の照合装置において、
    前記通信手段が、前記ユーザが正規のユーザではない旨を受信した場合に、前記ブラックリストデータベースは、前記ブラックリストデータベース中の前記ユーザの動作の情報に、ブラック確定フラグを立たせることを特徴とする照合装置。
  5. 請求項記載の照合装置において、
    前記ブラックリスト指標算出手段は、前記通信手段が受信した前記ユーザの動作の情報と、前記ブラックリスト中のレコードとを比較し、その近似の程度の高い前記ブラックリスト中のレコードの前記ブラック確定フラグが立っている場合は、前記ユーザが正規のユーザでない指標をより高く算出して送信することを特徴とする照合装置。
  6. 照合サーバが実行する、ユーザの動作の情報に基づき、前記ユーザが正規のユーザではない指標を求める照合方法において、
    前記ユーザの動作の情報を受信する通信ステップと、
    正規のユーザではないと判断された前記ユーザの動作の情報をブラックリストデータベースに記録するステップと、
    前記通信ステップにおいて受信した前記ユーザの動作の情報と、前記ブラックリストデータベース中のデータを比較し、その近似の程度から、前記ユーザが正規のユーザではない指標を算出して送信するブラックリスト指標算出ステップと、
    正規の前記ユーザの動作の情報をホワイトリストデータベースに記録するステップと、
    前記通信ステップで受信した前記ユーザの動作の情報が、前記ホワイトリストデータベース中のレコードに該当しないと判断された場合に、前記受信した前記ユーザの動作の情報を前記ブラックリストデータベースに登録するステップと、
    を含むことを特徴とする照合方法。
  7. コンピュータを、ユーザの動作の情報に基づき、前記ユーザが正規のユーザではない指標を求める照合装置として動作させるコンピュータプログラムにおいて、前記コンピュータに、
    前記ユーザの動作の情報を受信する通信手順と、
    正規のユーザではないと判断された前記ユーザの動作の情報をブラックリストデータベースに記録する手順と、
    前記通信手順において受信した前記ユーザの動作の情報と、前記ブラックリストデータベース中のデータを比較し、その近似の程度から、前記ユーザが正規のユーザではない指標を算出して送信するブラックリスト指標算出手順と、
    正規の前記ユーザの動作の情報をホワイトリストデータベースに記録する手順と、
    前記通信手順で受信した前記ユーザの動作の情報が、前記ホワイトリストデータベース中のレコードに該当しないと判断された場合に、前記受信した前記ユーザの動作の情報を前記ブラックリストデータベースに登録する手順と、
    を実行させることを特徴とするコンピュータプログラム。
JP2017252047A 2017-12-27 2017-12-27 サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム Active JP6506384B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017252047A JP6506384B2 (ja) 2017-12-27 2017-12-27 サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017252047A JP6506384B2 (ja) 2017-12-27 2017-12-27 サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2016092850A Division JP6347557B2 (ja) 2016-05-03 2016-05-03 サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム

Publications (2)

Publication Number Publication Date
JP2018063728A JP2018063728A (ja) 2018-04-19
JP6506384B2 true JP6506384B2 (ja) 2019-04-24

Family

ID=61967900

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017252047A Active JP6506384B2 (ja) 2017-12-27 2017-12-27 サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム

Country Status (1)

Country Link
JP (1) JP6506384B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7353072B2 (ja) 2019-06-19 2023-09-29 株式会社セブン銀行 リスト管理システム、リスト管理方法、およびリスト管理プログラム
US20210264299A1 (en) * 2019-06-26 2021-08-26 Rakuten, Inc. Fraud estimation system, fraud estimation method and program
JP6813711B1 (ja) * 2019-06-26 2021-01-13 楽天株式会社 不正推定システム、不正推定方法、及びプログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005134972A (ja) * 2003-10-28 2005-05-26 Pfu Ltd ファイアウォール装置
JP5160911B2 (ja) * 2008-01-23 2013-03-13 日本電信電話株式会社 本人認証装置、本人認証方法および本人認証プログラム
JP2010097467A (ja) * 2008-10-17 2010-04-30 Nomura Research Institute Ltd リスクベース認証システムおよびリスクベース認証方法
JP6113678B2 (ja) * 2014-03-13 2017-04-12 株式会社日立製作所 認証装置、認証システム及び認証方法
JP6506451B2 (ja) * 2018-05-31 2019-04-24 株式会社カウリス サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム

Also Published As

Publication number Publication date
JP2018063728A (ja) 2018-04-19

Similar Documents

Publication Publication Date Title
JP6347557B2 (ja) サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム
US9900346B2 (en) Identification of and countermeasures against forged websites
CA2736582C (en) Authorization of server operations
US10122830B2 (en) Validation associated with a form
US8850567B1 (en) Unauthorized URL requests detection
US20100175136A1 (en) System and method for security of sensitive information through a network connection
JP6113678B2 (ja) 認証装置、認証システム及び認証方法
KR20120135041A (ko) 액세스 감시 방법, 정보 처리 장치, 및 액세스 감시 프로그램을 저장한 컴퓨터 판독 가능한 매체
JP6564841B2 (ja) 照合サーバ、照合方法及びコンピュータプログラム
JP6506384B2 (ja) サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム
WO2015003182A1 (en) Network identity authentication using communication device identification code
US20150067772A1 (en) Apparatus, method and computer-readable storage medium for providing notification of login from new device
US20140101772A1 (en) Input method, input apparatus, and input program
US10887345B1 (en) Protecting users from phishing attempts
US10198417B2 (en) Systems and methods to input or access data using remote submitting mechanism
Wedman et al. An analytical study of web application session management mechanisms and HTTP session hijacking attacks
JP6506451B2 (ja) サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム
US11539697B1 (en) Method for controlling access to computer resources utilizing user device fingerprints
KR101592542B1 (ko) 사용자 인증 장치 및 방법
JP5947358B2 (ja) 認証処理装置、方法およびプログラム
KR102416576B1 (ko) 유가증권의 잔액 확인 서비스 제공 방법
KR102520329B1 (ko) 블록체인 기반 어뷰징 탐지 서비스 제공 시스템

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180329

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20180608

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20181220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190129

A25B Request for examination refused [due to the absence of examination request for another application deemed to be identical]

Free format text: JAPANESE INTERMEDIATE CODE: A2522

Effective date: 20190129

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190226

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190326

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190328

R150 Certificate of patent or registration of utility model

Ref document number: 6506384

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250