WO2019123665A1 - 照合サーバ、照合方法及びコンピュータプログラム - Google Patents

照合サーバ、照合方法及びコンピュータプログラム Download PDF

Info

Publication number
WO2019123665A1
WO2019123665A1 PCT/JP2017/046313 JP2017046313W WO2019123665A1 WO 2019123665 A1 WO2019123665 A1 WO 2019123665A1 JP 2017046313 W JP2017046313 W JP 2017046313W WO 2019123665 A1 WO2019123665 A1 WO 2019123665A1
Authority
WO
WIPO (PCT)
Prior art keywords
login
login history
database
history
control unit
Prior art date
Application number
PCT/JP2017/046313
Other languages
English (en)
French (fr)
Inventor
敦好 島津
Original Assignee
株式会社カウリス
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 株式会社カウリス filed Critical 株式会社カウリス
Publication of WO2019123665A1 publication Critical patent/WO2019123665A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication

Definitions

  • the present invention relates to a verification server that can be used by various sites that provide predetermined services to users.
  • the present invention also relates to a verification method by the verification server and a related computer program.
  • a user who wants to use this web site can access and log in to the web site using the given ID and password, and can receive a desired service using the web site.
  • a user who uses a shopping mall web site logs in to the web site using an ID and password, moves each page provided by the web site, and is able to find a desired product. It is possible to carry out the purchase of goods.
  • ID and password are often used to make available only to authorized users. By using this ID and password, it is believed that so-called malicious intruders can be eliminated and smooth use of services can be achieved.
  • OS -Browser-Language-IP address (representing the geographical location of the user who is performing access)
  • Time time of access
  • white List By recording these pieces of information and constructing a database as a so-called white list (White List), it is possible to detect that the user who has logged in takes an operation different from usual. In this way, it is preferable to execute additional authentication to confirm that the user does not behave as a malicious third party, for users who behave differently. For example, for the user's mobile phone, smart phone, etc. "The following websites are currently accessed using your ID. Is this access by yourself?
  • IP address IP address
  • OS personal computer
  • whitelists are often constructed based on the past several tens of accesses by the legitimate users, but may be smaller (several times) or larger (several 100 times). .
  • the whitelist may be configured to be replaced with new information and updated each time an authorized user accesses it.
  • it is also used to construct malicious third party data as a blacklist. It is considered that the use of these whitelists and Burrocklists can effectively distinguish between malicious third parties and legitimate users.
  • Patent Document 1 a white list, by using the black list, a device for searching for information of content is disclosed. It is described in the literature that privacy is protected by using both lists.
  • Patent Document 2 discloses an access control system that controls access to a Web site using a white list and a black list.
  • Patent Document 3 discloses a storage medium devised about a mechanism for restricting access to the storage medium. In the mechanism, whitelists and blacklists are used.
  • ID and password common ID and password are often used for a plurality of Web sites.
  • one set of ID and password is illegally acquired by a malicious third party
  • providing the information to the provider of the other web site is continuous by using the above-described common ID and password. It is considered effective to prevent unauthorized access.
  • a whitelist, a blacklist, and the like record information of a person who has accessed, and it is considered that it is possible to more efficiently detect whether a user who has made access is a legitimate user or not.
  • a malicious user performs an apparently different behavior from a legitimate user, for example, repeated failed access to the same site many times.
  • the whitelist and blacklist are human / static data of the person who has accessed, such as what login action (history) they are doing, and what login action they have performed so far There is almost no information on "login history” and "behavior”.
  • the present invention has been made in view of such problems, and an object thereof is to more efficiently determine whether the access is an unauthorized access or a legitimate access by an authorized user using a so-called login history.
  • the present invention is a communication unit that performs communication with the outside in order to solve the above problem, the communication unit receiving a login history from the outside and transmitting the log history to the control unit, and the communication unit
  • the verification server includes: the control unit that registers the log-in log in the log-in history database; and the log-in history database that holds the log-in log, wherein the control unit is configured to transmit the log-in log sent successfully. If it is a history, the login history is compared with the login history held by the login history database, and when the login is not the same behavior as the login behavior so far, a message indicating that the user is not like the person It is a collation server characterized by transmitting via the said communication part.
  • the present invention further includes a blacklist database for retaining information on malicious hackers, and the control unit is configured to determine whether the transmitted login history is a success history. And the login history is compared with the registered contents of the blacklist database, and if similar data exists, a message to the effect that the hacker is a malicious hacker is transmitted via the communication unit. Is a matching server.
  • the present invention further includes a white list database for retaining information on legitimate users, and the control unit is configured to determine whether the transmitted login history has a success history. And the login history is compared with the registered contents of the whitelist database, and if similar data exists, a message to the effect that the user is a legitimate user is transmitted via the communication unit. Is a matching server.
  • the present invention is a communication unit that performs communication with the outside in order to solve the above problem, the communication unit receiving a login history from the outside and transmitting the log history to the control unit, and the communication unit
  • the control unit which registers the log-in history in the log-in history database, the log-in history database which holds the log-in history, the black list database which holds information on malicious hackers, and the white which holds information on legitimate users And a list database, wherein the control unit compares the login history with the registered contents of the blacklist database when the transmitted login history is a success history, and the like.
  • the login history is compared with the login history held by the login history database, and the login history held by the login history database As a result of comparison, when the login history is not the same behavior as the previous login behavior, the login history is compared with the registered content of the whitelist database and compared with the registered content of the whitelist database. As a result, if similar data exists, a message to the effect that the user is a legitimate user is transmitted via the communication unit, and if similar data does not exist, a message to the effect that the user is not the person is the communication unit. It is a collation server characterized by transmitting via.
  • the communication unit receives a blacklist registration request from the outside, and transmits the blacklist registration request to the control unit. It is a collation server characterized by registering information on a malicious hacker included in a blacklist registration request transmitted from a communication unit in the blacklist database.
  • the communication unit receives a whitelist registration request from the outside and transmits the whitelist registration request to the control unit. It is a collation server characterized by registering information on a regular user included in a whitelist registration request transmitted from a communication unit in the whitelist database.
  • the present invention is a communication unit that performs communication with the outside in order to solve the above problem, the communication unit receiving a login history from the outside and transmitting the log history to the control unit, and the communication unit A verification method for verifying whether or not the login history is likely to be a person by using a verification server provided with the control unit that registers the log-in history in the login history database and the login history database that holds the login history
  • the control unit compares the login history with the login history held by the login history database when the transmitted login history is a success history, and the login is the one for the previous login. Send a message to the effect that you are not the person through the communication unit when the behavior is not the same as the behavior That step, a verification method characterized by comprising.
  • the present invention is a communication unit that performs communication with the outside in order to solve the above problem, the communication unit receiving a login history from the outside and transmitting the log history to the control unit, and the communication unit
  • the control unit which registers the log-in history in the log-in history database, the log-in history database which holds the log-in history, the black list database which holds information on malicious hackers, and the white which holds information on legitimate users
  • a verification method for verifying whether the login history is likely to be the person or not by using a verification server including a list database, and the control unit is configured to determine that the login history transmitted is a success history.
  • the login history is compared with the registered contents of the blacklist database, and similar data exists
  • the login history has the same behavior as the previous login behavior as a result of comparing with the login history held by the login history database, and the control unit comparing it with the login history held by the login history database.
  • the control unit If not, the step of comparing the log-in history with the registered content of the whitelist database, and if similar data exists as a result of comparison with the registered content of the whitelist database, the control unit The message that the user is a legitimate user If you send it, the same data is not present, a verification method characterized by comprising the steps of: a message that not like the person, and transmits via the communication unit.
  • the present invention is a communication unit that performs communication with the outside in order to solve the above problem, the communication unit receiving a login history from the outside and transmitting the log history to the control unit, and the communication unit A computer program that causes a computer to operate as a verification server including the control unit that registers the log-in log in the log-in history database, and the log-in history database that holds the log-in log, If the login history sent is a success history, the login history is compared with the login history held by the login history database, and if the login is not the same behavior as the previous login behavior, Procedure for transmitting a message to the effect that the user is not impersonated via the communication unit Which is a computer program for causing the computer to perform.
  • the present invention is a communication unit that performs communication with the outside in order to solve the above problem, the communication unit receiving a login history from the outside and transmitting the log history to the control unit, and the communication unit
  • the control unit which registers the log-in history in the log-in history database, the log-in history database which holds the log-in history, the black list database which holds information on malicious hackers, and the white which holds information on legitimate users
  • a computer program that causes a computer to operate as a verification server including a list database, and the control unit is configured to control the login history when the transmitted login history is a success history; If similar data exists as compared to registered content
  • a mechanism for determining whether or not the user is a legitimate user is constructed using the login history, so that access by a user who is determined not to be a legitimate user is more efficient. It becomes possible to detect
  • FIG. 18 is an explanatory view showing a state in which a legitimate user 18 accesses a plurality of sites in the second embodiment.
  • 5 is a flowchart showing the operation of the verification server 20 in the first embodiment.
  • 7 is a continuation of the flowchart showing the operation of the verification server 20 in the first embodiment.
  • 7 is a flowchart showing the operation of the verification server 40 in the second embodiment.
  • 7 is a continuation of the flowchart showing the operation of the verification server 40 in the second embodiment.
  • FIG. 8 is an explanatory diagram showing an example of contents registered in the whitelist database 48 and the blacklist database 28 in the first and second embodiments.
  • Embodiment 1 1-1 Basic Configuration
  • a plurality of sites use the common matching server to determine whether a user accessing the own site is a legitimate user.
  • FIG. 1 shows an example in which a plurality of such sites (for example, shopping malls) use a common matching server 20.
  • hacker 8 is a malicious hacker and is not a legitimate user, but is trying to access sites 10a, 10b, 10c, 10d, etc. by using an unauthorized means such as impersonating a legitimate user. .
  • the hacker 8 attempts unauthorized access to the sites 10a, 10b, 10c and 10d to be provided via a network such as the Internet.
  • the hacker 8 attempts unauthorized access using a method such as list type attack or spoofing.
  • Spoofing is an attack method that spoofs another person to access and hijack a predetermined site or service, and in recent years, a so-called list type attack is often used.
  • List-type attacks are one of the attack methods for hijacking the user's account for various sites and services. For example, it is a method of attempting to log in to a service or site using account information leaked from another service or system. This is an attack method that uses a large number of users using the same account name and password for multiple sites and services, and uses an account name (ID) and password leaked from a certain site. It attempts to break into other sites. If the same account name (ID) and password are used, the user's account may be taken over at the other site.
  • the list type attack is also called password list attack, list type account hacking, account list attack and the like.
  • hacker 8 gets the legitimate user's ID and password (PW) and uses this information to make use of a list-based attack, which is illegal for sites 10a, 10b, 10c, 10d. Try to access.
  • the verification server 20 receives login information (login history) at each of the sites 10a, 10b, 10c, and 10d from each of the sites 10 (a to d), and stores the information in an internal login history.
  • a characteristic configuration in the first embodiment is the verification server 20, which accesses the site 10 (a to c) in place of the site 10 (a to c) by accumulating log-in history from each site 10 (a to c). It is useful for each of the sites 10 (a to c) because it is determined whether or not a person is suspicious (not like the person) as a regular user.
  • the collation server 20 includes a communication unit 22, a control unit 24, a login history database 26, and a blacklist database 28.
  • the login history database 26 is a database for storing the history (login history) of login to the site in accordance with instructions and requests from various external sites. The login history is stored including whether the login succeeds or fails.
  • the communication unit 22 is an interface that communicates with various external sites and the like via a network such as the Internet, may use communication means other than the Internet, and is a communication interface that uses a so-called (mobile) telephone network. May be
  • the communication unit 22 corresponds to a preferable example of the communication unit in the claims.
  • the control unit 24 is means for managing the operation of the verification server 20. Specifically, the control unit 24 controls storage of the login history database 26 and the blacklist database 28, and executes various operations related to these databases. For example, it may comprise a CPU and a program executed by the CPU.
  • the program is a program in which processing executed by the verification server 20 is described. Moreover, the program corresponds to a suitable example of the computer program in the claims.
  • the login history database 26 is a database for storing login information (login history (login history)) when a user (or malicious hacker 8) logs in from a site 10 (a to d) supported by the verification server 20. It is.
  • the blacklist database 28 is a database that stores information on the opponent determined to be the malicious hacker 8.
  • the login history database 26 and the blacklist database 28 can also be configured by storage means such as a hard disk, for example. Alternatively, a semiconductor memory device or an optical memory device may be used.
  • the login history database 26 corresponds to a preferred example of the claimed login history database.
  • the blacklist database 28 also corresponds to a preferred example of the claimed blacklist database.
  • the login site 10a is the site 10a in which the user changes the password periodically. As a result, the hacker 8 will use the old ID and password for the site 10a, and the login will fail. Then, the site 10a transmits a login failure history that the login has failed to the verification server 20.
  • the verification server 20 stores the transmitted login failure history (login history (login history)) in the login history database 26 therein.
  • the site 10b is also a site 10b in which the user frequently updates the password, and as a result, the hacker 8 uses the old ID and password for the site 10b, and logs in. Fail. Then, similarly to the site 10a, the site 10b transmits to the verification server 20 a login failure history that the login has failed.
  • the verification server 20 stores the transmitted login operation (login history) in the login history database 26 therein.
  • the user does not update the password frequently, and as a result, the hacker 8 applies the ID and password of a legitimate user leaked from other places to the site 10c. And login is successful. Then, at the site 10c, the hacker 8 successfully logs in.
  • Each site 10 (a to d) transmits login information to the verification server 20 regardless of whether the login is successful or unsuccessful. Although login to the site 10c is successful, the login operation by the hacker 8 is transmitted to the verification server 20 as in the above-mentioned sites 10a and 10b, and the verification server 20 stores the login history in the login history database 26.
  • the verification server 20 stores in the login history database 26 whether the login history sent is a login failure history or a success history. As described above, at the site 10c, with the correct ID and password, the user authentication succeeds and the login succeeds. Then, the site 10 c transmits the log-in (success) history to the verification server 20. The operation of the verification server 20 when the login history is transmitted is described in the flowcharts of FIGS. 3 and 4.
  • step S3-1 in FIG. 3 first, when the login history is transmitted from the predetermined sites 10 (a to c), the communication unit 22 receives this and sends it to the control unit 24.
  • step S3-2 the control unit 24 sequentially stores the received login history in the login history database 26.
  • step S3-3 the control unit 24 checks the received login history and determines whether the login history is a success history. As a result of the determination, if it is a success history, the process proceeds to step S3-4, and if it is a failure history, the process ends.
  • step S3-4 the control unit 24 compares the received login history with the registered content of the blacklist database 28.
  • step S3-5 if similar data is registered as a result of the comparison in step S3-4, it can be determined that the person making the access is a malicious access person, so step S3-6. Migrate to On the other hand, if similar data is not registered, the process proceeds to step S4-1 in FIG.
  • step S3-6 the control unit 24 transmits a message indicating the malicious hacker via the communication unit 22 to the sites 10 (a to d) that have transmitted the login history. Then, the process ends. As a result, the sites 10 (a to d) can execute login denial and prevent malicious access.
  • the site 10c transmits the log-in success history
  • the operation when the similar data is not yet registered in the blacklist database 28 in step S3-5 in FIG. 3 will be described. Do. In this case, in step S3-5, since the same data as the accessing person is not registered in the blacklist database 28, the process proceeds to step S4-1 in FIG.
  • step S4-1 in FIG. 4 the control unit 24 refers to the login history of the site to which the sent login history has been sent, from the login history database 26.
  • step S4-2 the state of login of the log-in history referred to so far is compared with the log-in (success) log of this time to judge whether the behavior of the log-in operation is the same as before. As a result of the determination, if it is different from the behavior of the login operation so far, it is determined that the user (genuine user) is not, and the process proceeds to step S4-3.
  • the inspection operation of the login history is ended, and the storage operation of the login history is ended. Then, it waits for the next login history to be sent.
  • Judgment of behavior may use various methods.
  • the login operation in question may be compared with the content in the login history database 26, and it may be determined that the behavior is similar (common or similar) when there are many matching / similar parameters.
  • weights may be provided according to the type of parameter.
  • step S4-3 the control unit 24 notifies the site 10c that the user is not the person who is the legitimate user. For example, a message such as “I can not be identified” is transmitted to the site 10 c via the communication unit 22.
  • the verification server 20 of the present embodiment not only stores login history, but also Based on the log-in history sent, it is determined whether similar contents are registered in the blacklist database 28. If it is registered in the blacklist database 28, the fact is transmitted to the site 10. Furthermore, even if it is not registered in the blacklist database 28, it is determined whether the behavior of the login history is the same as the login history of the relevant site 10 (a to c) in the login history database 26, If it is the behavior of the login operation that is different from the previous one, a message to that effect (for example, a message such as “not unique”) is transmitted to the site 10 c. By such an operation, each site 10 can efficiently determine whether the accessing person is a legitimate user (whether or not it is a malicious access person), which is convenient.
  • Execution of two-factor authentication at the site 10c In the example shown in FIG. 1, the site 10c receives a message that the login is successful but "not unique" from the verification server 20 (step S4-3 in FIG. 4). ). The site 10 c can receive this, for example, perform two-factor authentication 30. Two-factor authentication is a method of performing authentication based on two different factors. For example, the site 10c transmits the one-time password to the mobile phone of the "user" who is trying to log in. The user reads the one-time password from his mobile phone and inputs it to the site 10c. If the input one-time password is the same password as the one-time password transmitted by the site 10c, the site 10c determines that the user is a valid person.
  • authentication data for so-called authentication, “what only the person knows (a password)”, “thing owned only by the person (a cash card, a mobile phone)”, “characteristic of the person itself (a biometric)
  • two-factor authentication a method of performing authentication using two different types of this is called “two-factor authentication”.
  • a "mobile phone” newly owned only by the user is used as the second authentication data.
  • the mobile phone with that phone number is based on what only the owner should own.
  • such two types of authentication data are used, but other two types of authentication data may be used.
  • the matching server 20 registers the contents in the black list database 28 upon receiving the incoming black list registration request. Specifically, first, the communication unit 22 receives the blacklist registration request. Next, the communication unit 22 transmits a blacklist registration request to the control unit 24. When receiving the blacklist registration request, the control unit 24 registers information about the hacker 8 in the blacklist database 28 according to the request.
  • the registered content of the blacklist database 28 may be any registered content as long as the hacker 8 can be identified.
  • Login History Database 26 and Black List Database 28 Utilization of Login History Database 26 and Black List Database 28 According to the example of FIG. 1, an example is described in which hacker 8 executes a list type attack on site 10 d as well as other sites 10 a, 10 b and 10 c. ing.
  • the site 10 d also uses the verification server 20, and the login history is registered in the login history database 26 in the verification server 20. Also, if it is determined that the site 10d is not the person as described above, the site 10d makes a registration request to the blacklist database 28.
  • the site 10d first transmits the log-in history to the verification server 20, similarly to the sites 10a, 10b and 10c.
  • the operation of the verification server 20 in this case is as described in the flowchart of FIG.
  • the process proceeds with steps S3-3, S3-4, and S3-5.
  • the accessor who has logged in is already registered in the blacklist database 28. That is, as described above, the hacker 8 is registered in the blacklist database 28 by the blacklist registration request (see FIG. 1) transmitted by the site 10c. Therefore, with respect to the log-in history of the site 10d, the verification server 20 determines that similar data exists in step S3-5 of FIG. As a result, the process proceeds to step S3-6, where a message indicating that the hacker is a malicious hacker on the blacklist is sent by the control unit 24 to the site 10d (via the communication unit 22). By receiving this message, the site 10d can know that the accessor hacker 8 is a malicious hacker 8 and can perform login denial.
  • the site 10 d can use the login history database 26 and the blacklist database 28 registered by other sites 10 (a to c), and a person who attempts to perform an unauthorized login. Can be detected efficiently. That is, based on the contents recorded in the other sites 10 (a to c), it can be determined whether the person who has accessed is a valid user.
  • content to be recorded various types of content can be set.
  • login history IP address of the accessing person, time, input speed of input ID and password, location information, type of accessed device, type and version of browser being used, name and version of OS, etc.
  • location information can be included in the registration content. Among these, only part of the information may be registered content, or many other types of information may be included.
  • data serving as an index or a degree of reliability may be registered in the login history database 26 or the blacklist database 28. Further, for example, when it is determined that the hacker is a malicious hacker and the login is rejected 32 as a result of the two-factor authentication 30 described above, a flag determined to be a malicious hacker is displayed in the login history (login history in the login history database 26). It may be added.
  • the control unit 24 searches the login history database 26 and searches the blacklist database 28 based on the data transmitted from each of the sites 10 (a to d).
  • each site 10 (a to d) who is the user of the verification server 20 may be configured to be able to directly access the login history database 24 and the blacklist database 28. Then, the site 10 (a to d) may be configured to be able to judge from the contents thereof.
  • the sites 10 such as shopping malls are those who have accessed Since it is possible to refer to the access history of the user, it is possible to efficiently detect whether or not the user is a valid user.
  • the verification server 20 is based on the contents of the login history database 26, It can detect "non-identifying" access. Therefore, each site 10 (a to d) can know “suspicious” access that is difficult to judge only by the ID and password. In particular, the verification server 20 determines who is “suspecting” and “unfamiliar” based on the access history of the other site 10, so the site 10 (a to d) to be used is “suspected”. It is possible to easily know a person who is not "true” and, as described above, can execute two-factor authentication and the like.
  • the site 10 (a to d) is accessed for the first time It may be possible to determine whether the user is a legitimate user or not.
  • the verification server 20 constructs (registers) the blacklist database 28, when a corresponding person is found in the blacklist database 28, login refusal is immediately made. It is possible to secure the security of the site more strongly.
  • Each site may query the matching server 20 to determine whether each person 10 is registered in the blacklist database 28 or not. Further, when each site 10 tries to register a login history as shown in FIG. 1, the control unit 24 of the collation server 20 may separately confirm the registered contents of the blacklist database 28. In this case, when the corresponding content is registered in the blacklist database 28, it is preferable that the control unit 24 of the verification server 20 transmits a message to that effect to the site 10.
  • Embodiment 2 In the first embodiment and FIG. 1 described above, the matching server 20 including the login history database 26 and the blacklist database 28 has been described. With such a configuration, unauthorized access can be efficiently determined by combining the login history and the blacklist. However, it is also preferable to combine login history with a whitelist. In the second embodiment, an example in which the login history and the white list are combined as described above will be described.
  • FIG. 2 shows an example in which a plurality of such sites (for example, shopping malls) use the common matching server 40.
  • the user 18 is a general user or a regular user who has registered properly.
  • the user 18 is trying to access the sites 10a, 10b, 10c, 10d, etc. by the normal login operation.
  • the user 18 performs a normal login on the sites 10a, 10b, 10c and 10d to be provided via a network such as the Internet.
  • the user 18 registers and acquires an ID and a password by registering at the site.
  • the access is performed on the sites 10a, 10b, 10c, and 10d using the ID and password (PW) of the registered user.
  • the verification server 40 receives login information (login history) at each of the sites 10a, 10b, 10c, and 10d from each of the sites 10 (a to d), and stores the information in an internal login history.
  • the verification server 40 stores login histories from each of the sites 10 (a to d) to replace the respective sites 10 (a to d). It is convenient for each site 10 (a to d) because it is determined whether the person who has accessed the content is suspicious (not like the person) as a regular user.
  • the operation relating to the login history is substantially the same as that of the first embodiment described above.
  • the verification server 40 includes a communication unit 42, a control unit 44, a login history database 46, and a white list database 48.
  • the login history database 46 is a database similar to the login history database 26 of the first embodiment (FIG. 1).
  • the communication unit 42 is also a communication interface similar to the communication unit 22 of the first embodiment (FIG. 1).
  • the communication unit 42 also corresponds to a preferable example of the communication unit in the claims.
  • the control unit 44 controls the operation of the verification server 40. Specifically, the control unit 44 controls writing and reading to the login history database 46 and the white list database 48, and executes various operations related to these databases. Do. For example, it may comprise a CPU and a program executed by the CPU.
  • the program is a program in which processing executed by the verification server 40 is described. Moreover, the program corresponds to a suitable example of the computer program in the claims.
  • the whitelist database 48 is a database that stores information on the other party determined to be the authorized user 18.
  • the second embodiment is an embodiment relating to the verification server 40 capable of linking the log-in history with the whitelist to provide efficient determination.
  • the whitelist database 48 can be configured by storage means such as a hard disk, for example. Alternatively, a semiconductor memory device or an optical memory device may be used.
  • the login history database 46 corresponds to a preferred example of the claimed login history database.
  • the whitelist database 48 also corresponds to a preferred example of the claimed whitelist database.
  • the login site 10a is a site 10a registered by the user 18 as an authorized user and having acquired the ID and password regularly, and the user 18 successfully logs in according to the normal procedure. Then, the site 10a transmits, to the verification server 40, a login success history that the login is successful.
  • the verification server 40 stores the transmitted login success history (login history (login history)) in the login history database 46 therein.
  • the site 10b is also a site 10b in which the user 18 updates the password frequently, and as a result, the user 18 logs in by using the correct ID and password for the site 10b. success. Then, similarly to the site 10a, the site 10b transmits to the verification server 40 a login success history that the login is successful.
  • the verification server 40 stores the transmitted login operation (login history) in the login history database 26 therein.
  • the site 10c like the sites 10a and 10b, allows the user 18 to log in normally using the correct ID and password. As a result, the site 10 c also transmits login information to the verification server 40. The site 10 c also transmits the login operation by the user 18 to the verification server 20, and the verification server 40 registers the login history in the login history database 46. Next, the operation of the verification server 40 to which the login history has been transmitted will be described based on a flowchart.
  • the verification server 40 registers in the login history database 46 whether the login history sent is a login failure history or a success history. The operation of the verification server 40 when the login history is transmitted is described in the flowcharts of FIGS. 5 and 6.
  • step S5-1 in FIG. 5 first, when the login history is transmitted from the predetermined sites 10 (a to c), the communication unit 42 receives this and sends it to the control unit 44.
  • step S5-2 the control unit 44 sequentially registers the sent-in log in the log-in history database 46.
  • step S5-3 the control unit 44 checks the received login history, and determines whether the login history is a success history. If the result of the determination is that it is a success history, the process proceeds to step S5-4. On the other hand, if it is a failure history, the processing on the login history of the verification server 40 is finished, and the transmission server waits for transmission of the next login history. In the case shown in FIG. 2, since the normal login operation by the normal user 18 is represented, the process proceeds to step S5-4 in that case.
  • step S5-4 the control unit 44 refers to the login history of the site 10 (a to c) to which the login history has been sent so far from the login history database 46.
  • step S5-5 the control unit 44 compares the log-in state of the log-in history so far referred to and the log-in (success) log of this time, and determines whether the behavior of the log-in operation is the same as before. Do. As a result of the determination, if it is different from the behavior of the login operation so far, it is determined that the behavior is not the person (authorized user) and the process proceeds to step S5-6.
  • the inspection operation of the login history is ended, and the storage operation of the login history is ended. Then, it waits for the next login history to be sent.
  • a login that is not unique is performed. This is an example in which a different login is performed, such as logging in from a terminal different from usual or logging in from a new position (geographical position). In such a case, as described above, the process proceeds to step S5-6.
  • step S5-6 the control unit 44 compares the login history stored this time with the registered content of the white database 48. Then, the process proceeds to step S6-1 in FIG. In step S6-1 in FIG. 6, if similar data is registered as a result of the comparison in step S5-6, it is determined that the person who has made the access is an access person who has a valid right, The process moves to step S6-2. On the other hand, when similar data is not registered, the process proceeds to step S6-3 in FIG.
  • step S6-2 the control unit 44 transmits, for example, a message such as “It is a legitimate user listed in the white list” to the site (a to d) via the communication unit 42. Thereafter, the process of the login history is ended. As a result, it is possible to recognize that the site 10 (a to d) is confirmed to be a legitimate user 18 although access is performed with behavior that is not the same as the person.
  • step S6-3 the control unit 44 transmits, via the communication unit 42, a message such as “not impersonal” to the sites 10 (a to d) from which the login history has been transmitted. Then, the process ends.
  • the sites 10 (a to d) can recognize that the access has been performed with the behavior that the ID and password are correct but are not the same as the person.
  • the verification server 40 of this embodiment not only stores login history, but also The transmitted login history is compared with the previous login history, and if it is not the same behavior, it is determined whether the same content is registered in the whitelist database 48 or not. If it is registered in the whitelist database 48, the fact is transmitted to the site 10. Furthermore, if the login history is not registered in the whitelist database 48, the login history behavior is different from the past login behavior, so that effect (for example, a message such as "not unique") It is sent to 10 (10c in the above example). By such an operation, each site 10 can efficiently determine whether the accessing person is a legitimate user (whether or not it is a malicious access person), which is convenient.
  • Execution of two-factor authentication in the site 10c In the example shown in FIG. 2, the site 10c receives a message that the login is successful but “not unique” from the verification server 40 (step S6-1 in FIG. 6) ). In response to this, the site 10 c can perform, for example, two-factor authentication 50.
  • the two-factor authentication is as described in the first embodiment.
  • login permission 52 in FIG. 2 If the login permission 52 is obtained, it is determined that the user is a legitimate user 18 and the site 10 c transmits a whitelist registration request to the verification server 40.
  • registration server 40 Upon receipt of the incoming white list registration request, registration server 40 registers the contents in white list database 48. Specifically, first, the communication unit 42 receives the whitelist registration request. Next, the communication unit 42 transmits a whitelist registration request to the control unit 44. When the control unit 44 receives the whitelist registration request, the control unit 44 registers information on the user 18 in the whitelist database 48 according to the request.
  • the registered content of the whitelist database 48 may be any registered content as long as the user 18 can be identified.
  • Utilization of login history database 46 and white list database 48 (operation in the case of site 10 d)
  • site 10 d Utilization of login history database 46 and white list database 48 (operation in the case of site 10 d)
  • the site 10 d also uses the verification server 40, and registers the login history in the login history database 46 in the verification server 40.
  • the site 10d makes a registration request to the whitelist database 48.
  • the site 10d first transmits the log-in history to the verification server 40, similarly to the sites 10a, 10b and 10c.
  • the operation of the verification server 40 in this case is as described in the flowchart of FIG.
  • the processing proceeds with steps S5-3, S5-4, and S5-5.
  • step S5-5 if the behavior is the same in comparison with the login history, the processing in the verification server 40 ends, but if the behavior in the comparison with the login history is different, the white list is processed in step S5-6. A comparison process with the database 48 is performed.
  • the accessor who has logged in is already registered in the white list database 48. That is, as described above, the user 18 is registered in the whitelist database 48 by the whitelist registration request (see FIG. 2) transmitted by the site 10c.
  • the verification server 40 determines in step S6-1 of FIG. 6 that similar data exists.
  • the control unit 48 transmits, for example, a message such as “it is registered in the white list” to the site 10d via the communication unit 42.
  • the process in the verification server 40 ends.
  • the site 10 d can use the login history database 46 registered in the other sites 10 (a to c) and the white list database 48 and can be a legitimate user 18. It can be detected efficiently. That is, based on the content recorded by the other site 10, it can be determined whether the accessing person is a valid user or not.
  • the recorded contents can be set to various contents.
  • As login history IP address of the accessing person, time, input speed of input ID and password, location information, type of accessed device, type and version of browser being used, name and version of OS, etc. And various parameters can be included in the registration content.
  • data serving as an index or a degree of reliability may be registered in the login history database 46 or the white list database 48. Further, for example, when it is determined that the user is the authorized user 18 and the login is permitted 52 as a result of the two-factor authentication 50 described above, it is determined that the authorized user 18 is the login history (login history in the login history database 46). You may add a flag.
  • the control unit 44 searches the login history database 46 based on the data transmitted from each of the sites 10 (a to d) and searches the white list database 48.
  • each site 10 (a to d) who is the user of the verification server 40 may be configured to be able to directly access the login history database 24 and the white list database 48. Then, the site 10 (a to d) may be configured to be able to judge from the contents thereof.
  • the verification server 40 can detect “impersonal” access based on the contents of the login history database 46. Therefore, each site 10 (a to d) can know "suspicious” access that is difficult to judge only by the ID and password. In particular, since the verification server 40 can determine a person who is “suspecting” or “unfamiliar” based on the access history of the other site 10, the site 10 (ac) to be used is “suspected”. It is possible to easily know the person who is not the person himself / herself and to execute two-factor authentication or the like as described above based on the judgment of the collation server.
  • the site 10 (a to d) is accessed for the first time It may be possible to determine whether the user is a legitimate user or not.
  • the verification server 40 constructs (registers) the whitelist database 48, if a corresponding person is found in the whitelist database 48, the site 10 (a ⁇ d) can grant login permission immediately (even if the accessor is the first-time accessor to his site).
  • Each site may query the matching server 40 and each site 40 may individually determine whether a person corresponding to the white list database 48 is registered.
  • the control unit 44 of the verification server 40 may separately confirm the registered content of the whitelist database 48. In this case, when the corresponding content is registered in the whitelist database 48, it is also preferable that the control unit 44 of the verification server 40 transmits a message to that effect to the site 10.
  • Embodiments 1 and 2 Summary (1) Effects As described above, in Embodiments 1 and 2, the login history databases 26 and 46 are constructed and shared among a plurality of sites 10 (shared by the verification servers 20 and 40). Because of this, it is possible to efficiently detect access with behavior different from before.
  • the blacklist database 28 since the blacklist database 28 is constructed, it can be efficiently determined that the hacker is a malicious hacker. In particular, since the information can be shared by a plurality of sites by the verification server 20, unauthorized access can be prevented more efficiently.
  • the malicious hacker 8 may include a case where a human being operates to execute access, or a case where a computer or the like mechanically executes an access by impersonating the legitimate user.
  • the white list database 48 since the white list database 48 is constructed, it is possible to determine a user who is known to be a proper access person regardless of the behavior. In particular, since the information can be shared by the verification server 400 with a plurality of sites, it can be efficiently determined that the user is a valid user.
  • the login history database 26, 46 may record various login information. For example, various types of data shown in FIG. 7 may be registered for each login. An explanatory view showing an example of registration of the login history databases 26, 46 is shown in FIG. In this figure, an example of the information registered in one login is shown, and in fact, such information may be registered in the login history database 26, 46 each time of login. As shown in the figure, the contents recorded in the login history databases 26, 46 may be divided into, for example, five types.
  • the first type of information is user information, mainly an ID and a password.
  • This user information is information for identifying the user who is the subject of the operation. For example, a hashed ID and a hashed password may be recorded as the ID and the password. This is for the purpose of making the amount of data compact and facilitating comparison operation and the like, and also for preventing complete identification of an individual and reducing the possibility of leakage of personal information.
  • the second type of information is terminal information, which is information of a terminal used when the user accesses the site 10, and the type of terminal used, the type of OS, etc. are recorded. Also, information on the language used may be recorded.
  • the third type of information is information such as a browser used by the user. This browser information is also recorded for each terminal used. Even when there are multiple types of browsers to use, information on multiple browsers is recorded.
  • a browser it may include all means / programs for accessing the site 10 in general.
  • the fourth type of information is the IP address of the accessing user.
  • the location of the user can be known from this IP address.
  • the fifth type of information is page transitions. This information is, for example, a referrer URL or the like, as shown in FIG. 7, and indicates where the user has transitioned to the site.
  • login history examples of login history, and less information may be registered as the login history. Although the above description and FIG. 7 show five types of examples, the number of types may be smaller (for example, one type) or more. Further, the contents of the login log to be registered may be different depending on the site to be used. These login histories are registered and accumulated in the login history databases 26 and 46 for each login.
  • the contents of the white list database 48 and the black list database 28 constructed in the first and second embodiments may include various parameters. Both may be the same as the content to record, and may be different content.
  • FIG. 8 a recording example of the whitelist database 48 recording information of a user determined to be a legitimate user, and a recording of a blacklist database 28 recording malicious hacker information spoofing a legitimate user
  • An explanatory diagram showing an example is shown. As shown in the figure, the contents recorded in the whitelist database 48 (and the blacklist database 28) are substantially the same as the registered contents of the login history databases 26, 46 shown in FIG. It is divided.
  • the first to fourth types of information are as described above.
  • the fifth type of information is page transitions.
  • This information is also, for example, the referrer URL, as shown in FIG.
  • the whitelist database 48 and the blacklist database 28 may additionally include information indicating what page has been viewed on the website 10. For example, in the example of FIG. 8, after logging in, after confirming the purchase history on the purchase history page, the authorized user of the whitelist database 48 browses the point confirmation page to confirm the available points, etc. May show browsing history. Also, a malicious hacker who spoofs a legitimate user of the blacklist database may go to the point exchange page immediately after login and be a browsing history to try to exchange points. Thus, it is empirically known that the pages browsed on the Web site 10 are significantly different from malicious hackers who have become legitimate users.
  • the time spent in the web site 10 may also be recorded. It is known that malicious hackers generally spend less time in the Web site 10 compared to legitimate users. As such time information, the time spent on each page viewed may be recorded.
  • a malicious hacker may be a human or a machine (computer) spoofing a regular user.
  • a computer spoofs a legitimate user
  • the time spent staying on the entire Web site 10 and the time spent staying on each page are often very short and can be distinguished from humans based on the time spent staying In some cases.
  • the speed of character input may be included. It is empirically known that malicious programs spoofing humans have an abnormally fast key input.
  • the recording content described here is an example, and more various kinds of information may be recorded. Also, the recorded contents described here represent a standard example, and a white list database or a black list database may be configured using less types of information. In the above description and FIG. 8, five types of examples are shown, but the number of types may be smaller, or the number of types may be different between the blacklist and the whitelist. Depending on the application, even one type is useful.
  • Embodiment 3 Details of the verification servers 20 and 40, related techniques (1)
  • the verification servers 20 and 40 described above on the verification server are servers that are used from a plurality of sites 10 and store login histories. Because the login history of a given user 18 can be accumulated more than the individual sites 10 themselves accumulate login history, whether or not the access is the same as before from the login behavior Can be determined more efficiently, and the result can be notified to each site 10.
  • each site 10 can perform further authentication of legitimacy, such as two-factor authentication 30, for the user 18, and can detect unauthorized access efficiently. Furthermore, each site 10 can make a registration request to the blacklist database 28 or the whitelist database 48 based on the result of further verification of the legitimacy. Therefore, if it is registered in the blacklist database 28 or the white database 48, it may be more reliably determined whether the access user is a valid user (the (verification server 24 or 44 of the verification server 20 or 40)). It is possible to provide the result to each site 10.
  • the login history databases 26 and 46 accumulate login history both in the case of a successful login and in the case of a login failure. Although various methods can be adopted as the accumulation method, since the log is limited, it is also preferable to delete old data as appropriate.
  • the login history databases 26 and 46 may store the information of FIG. 7 described above for each login, the login success history of the same user 18 is stored only for the latest predetermined number, and deleted in the order of oldness It is also preferable to Such operations may be performed by the control units 24 and 44.
  • the login history databases 26, 46 also accumulate the information of FIG. 7 described above for each login failure history for each login, but it is determined whether these histories are the same hacker 8 or not. Hateful. Therefore, it is also preferable to collectively determine the maximum amount of accumulated data as a predetermined amount in advance for the login failure history, and delete the old login failure history when the storage capacity of the predetermined amount is exceeded. Such operations may also be performed by the control units 24 and 44.
  • the amount of accumulated data may be determined for each site. It is also preferable to determine the maximum amount of accumulated data for accumulating log-in failure history for each site 10, and delete from the old log-in failure history if the amount is exceeded. Alternatively, the storage time may be determined, and old login history beyond that time may be deleted. Such operations may also be performed by the control units 24 and 44.
  • the collation server 20 including the blacklist database 28 and the collation server 40 including the whitelist database 48 may be configured to have the blacklist database 28 and the whitelist database 48 together.
  • Comparison with Registered Contents of Black List Database 28 Comparison with Login History Comparison with registered contents of the white list database 48 may be executed in order. Specifically, processing may be performed to shift to step S5-4 in FIG. 5 following “No” in step S3-5 in FIG.
  • the collation server 20, 40 in this embodiment can be a particularly useful countermeasure against such continuous unauthorized access.
  • not only the ID and password of the user 18 but also the login history of the operation of the user 18 and the hacker 8 are recorded to construct the login history databases 26, 46, Provides a mechanism to share between sites. Therefore, it is possible to perform authentication of the user 18 and detection of the hacker 8 more efficiently than the case where only one site manages the history of the user on its own.
  • the verification servers 20 and 40 may be located anywhere on the Internet as long as they can be accessed from each site 10. For example, it may be located in the same server as a predetermined site 10 (e.g. 10a). In this case, a site with a matching server can be configured in combination with the matching server + site.
  • the number of records of the same user information (record) in the whitelist database 48 may be fixed (for example, n (n is a natural number)) and set, but may be a smaller number, or It does not matter if there are many. Further, the number of registrations may be dynamically adjusted according to the situation.
  • the number of records in the blacklist database 28 is not limited, but the maximum number of registrations may be limited in consideration of the calculation speed of the comparison and the like. In that case, for example, processing such as deletion from an old record may be performed.
  • the data in the whitelist database 48 is recorded based on the actual access, but it is also possible to artificially record typical regular data in advance.
  • the blacklist database 28 may artificially store an example of unauthorized access which has been found in advance.
  • the data in the whitelist database 48 may be updated each time a new access is made, and old data may be deleted, but artificially fixed records may be designated. . This is in consideration of the user 18 who has low access frequency.
  • the records of the whitelist database 48 and the blacklist database 28 may be appropriately tuned by artificial means or other means, and the less important records are deleted manually. It is also good. Various artificial work may be performed.
  • the hashed ID and the hashed password are recorded in the whitelist database 48 and the blacklist database 28, data that is not hashed may be used. You may use an encrypted ID and password.

Abstract

いわゆるログインヒストリーを利用してそのアクセスが、不正なアクセスであるか、正規ユーザによる正当なアクセスであるか、をより効率的に検知する技術を提供する。外部からログイン履歴を受信し、制御部に送信する通信部と、通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する制御部と、ログイン履歴を保持するログインヒストリーデータベースと、を備える照合サーバであって、制御部は、送信されてきたログイン履歴が成功履歴である場合に、そのログイン履歴を、ログインヒストリーデータベースが保持するログイン履歴と比較し、そのログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、通信部を介して送信することを特徴とする照合サーバ。

Description

照合サーバ、照合方法及びコンピュータプログラム
　本発明は、ユーザに対して所定のサービスを提供する各種サイトが利用しうる照合サーバに関する。また、当該照合サーバによる照合方法及び関連するコンピュータプログラムに関する。
　従来、インターネットなどのネットワーク上でユーザに対して種々のサービスを提供するＷｅｂサイト（サービス提供システム）が知られている。
　このＷｅｂサイトを利用したいユーザは、与えられているＩＤとパスワートを用いて、Ｗｅｂサイトにアクセス・ログインを行い、Ｗｅｂサイトを利用して所望のサービスを受けることができる。
　例えば、ショッピングモールのＷｅｂサイトを利用するユーザは、ＩＤとパスワードを利用してそのＷｅｂサイトにログインし、そのＷｅｂサイトが提供する各ページを移動し、所望の商品を見つけることができたページで商品の購入を実行することができる。
　従来のＷｅｂサイトにおいては、正規のユーザのみが利用可能にするために、ＩＤとパスワードが利用される場合が多い。このＩＤとパスワードとを利用することによって、いわゆる悪意の侵入者を排除することができ、円滑なサービスの利用を図ることができると考えられている。
　＜悪意のアクセス＞
　しかし、近年、悪意のある第三者が不正な手段を用いて他人のＩＤとパスワードとを入手する事件が報告されている。このように悪意のある第三者が（正規のユーザである）他人のＩＤとパスワードを用いて、Ｗｅｂサイトにログインした場合、そのＩＤとパスワードだけでは、そのログイン者が、正規のユーザか、悪意のある第三者かを区別することは困難である。
　そこで、近年、正規のユーザが実行するログイン以降の動作の情報を記録しておき、ホワイトリストとしてデータベース化しておく仕組みが知られている。ここで、記録する動作の情報としては、例えば、下記のような情報が好ましい。
　・ＯＳ
　・ブラウザ
　・言語
　・ＩＰアドレス（アクセスを実行しているユーザの地理的な位置を表す）
　・時間（アクセスした時刻）
これらの情報を記録し、いわゆるホワイトリスト（ＷｈｉｔｅＬｉｓｔ）としてデータベースを構築しておけば、ログインしてきたユーザがいつもと異なる動作をとっていることを検知することが可能である。このように、いつもと異なる動作をとるユーザに対しては、悪意のある第三者ではないことを確認するため、追加認証を実行することが好ましい。例えば、ユーザの携帯電話やスマートホン等に対して、「現在貴方のＩＤを用いて以下のＷｅｂサイトへのアクセスが行われています。このアクセスは貴方自身によるものですか。そうでない場合は、ＮＯボタンを押下（タッチ）してください」というメッセージを送り、「ＮＯボタン」が押された（タッチされた）場合は、正規のユーザではなく、悪意のある第三者がアクセスしていると判断することができる。そして、直ちに当該ユーザのアクセスを切断する処理をとることができる。
　例えば、いつもとは別の場所（ＩＰアドレス）からアクセスされた場合や、いつもとは異なるパソコン（ＯＳ、ブラウザ）からアクセスされた場合等が挙げられる。このような場合に、追加認証が実行されて、正規のユーザか否かが確認される（本人確認とも呼ばれる）。
　また、ホワイトリストは、当該正規のユーザによる過去の数１０回程度のアクセスに基づき構築される場合が多いが、より少ない場合もあり（数回）、またより多い場合（数１００回）もある。さらに、ホワイトリストは、正規のユーザがアクセスする度に新しい情報と置き換えられ、更新されるように構成される場合もある。
　また、同様に、悪意の第三者のデータを、ブラックリストとして構築することも利用されている。これら、ホワイトリストや部落リストを用いれば、悪意の第三者と、正規のユーザとを効率的に区別することができると考えられている。
　先行特許文献
　例えば、下記特許文献１には、ホワイトリストと、ブラックリストとを用いて、コンテンツの情報を検索する装置が開示されている。両リストを用いることによって、プライバシーが保護されると同文献には記載されている。
　また、例えば、下記特許文献２には、ホワイトリストと、ブラックリストとを用いて、Ｗｅｂサイトへのアクセスを制御するアクセス制御システムが開示されている。
　また、例えば、下記特許文献３には、記憶媒体へのアクセスを制限する仕組みについて工夫された記憶媒体が開示されている。その仕組みにおいて、ホワイトリスト、ブラックリストが利用されている。
特開２０１２－１５９９３９号公報 特開２０１１－３１３２号公報 特開２０１１－２４８４７４号公報
　このように、従来のＷｅｂサイトにおいては、正規ユーザのアクセスの動作の情報をホワイトリストとして記録しておき、このホワイトリストと大きく異なる動作をとるユーザに対しては適宜追加認証を行っていた。
　しかし、悪意のある第三者は、当然巧妙に正規のユーザ本人になりすましているので、それを見破ることは一般に困難であることもある。したがって、セキュリティ担当者の経験則によって対処している場合も多い。例えば、金融機関のＷｅｂサイトにおける預金口座からの引き出し限度額一杯の預金の引き出しは、悪意のある第三者である可能性が高い等の経験則に頼り、悪意のある第三者を発見している場合もある。
　さらに、ＩＤやパスワードは、複数のＷｅｂサイトに対して、共通のＩＤとパスワードが用いられる場合も多い。この場合、１組のＩＤ及びパスワードが不正に悪意のある第三者に取得されてしまった場合、複数のＷｅｂサイトに対して連続して不正なアクセスが実行されてしまう場合も散見される。
　このような場合、ある一つのＷｅｂサイトへの不正アクセスが検出された場合に、その情報を他のＷｅｂサイトの事業者に提供することが、上述した共通のＩＤとパスワードを利用することによる連続した不正アクセスを防ぐために効果的であると考えられる。
　本願発明者は、そのような仕組みについて、２０１６年５月３日に、特許出願の特願２０１６－０９２８５０（以下、先行特許出願と呼ぶ）をしている。
　本願発明者によるこの先行特許出願においては、ホワイトリストだけでなく、ブラックリストを用いて、不正なアクセスを効率的に検出し、その結果を共有する仕組みを提案している。
　ホワイトリストやブラックリスト等は、アクセスしてきた者の情報を記録するものであり、これらに基づきアクセスをしてきたユーザが正規ユーザか否かの検知をより効率的にすることができると考えられる。
　しかし、悪意でアクセスを行う者は、例えば同一のサイトに対して何度も失敗アクセスを繰り返すような、正規のユーザとは明らかに異なる振る舞いを行うことが経験的に知られている。
　ここで、ホワイトリストやブラックリストは、アクセスしてきた者の人的・静的なデータであり、どのようなログイン行為（履歴）を行っているか、どのようなログイン動作をこれまで実行してきたかのような「ログイン履歴」「振る舞い」に関する情報はほとんど有していない。
　そこで、上述したホワイトリスト、ブラックリストに加えて、いわゆるログインヒストリーを用いて、アクセスしてきた者の振る舞いに基づいて、正規ユーザか、悪意のアクセス者か、を判断する仕組みがあれば好ましいが、未だ、そのような仕組みは知られていない。
　本発明は、係る課題に鑑みなされたものであり、その目的は、いわゆるログインヒストリーを利用してそのアクセスが、不正なアクセスであるか、正規ユーザによる正当なアクセスであるか、をより効率的に検知する技術を提供することである。
　（１）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、を備える照合サーバであって、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信することを特徴とする照合サーバである。
　（２）また、本発明は、（１）記載の照合サーバにおいて、さらに、悪意のハッカーの情報を保持するブラックリストデータベース、を備え、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信することを特徴とする照合サーバである。
　（３）また、本発明は、（１）記載の照合サーバにおいて、さらに、正規のユーザの情報を保持するホワイトリストデータベース、を備え、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信することを特徴とする照合サーバである。
　（４）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、悪意のハッカーの情報を保持するブラックリストデータベースと、正規のユーザの情報を保持するホワイトリストデータベースと、を備える照合サーバであって、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信し、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信することを特徴とする照合サーバである。
　（５）また、本発明は、（２）又は（４）記載の照合サーバにおいて、前記通信部は、外部からブラックリスト登録要求を受信し、前記制御部に送信し、前記制御部は、前記通信部から送信されてきたブラックリスト登録要求に含まれる悪意のハッカーの情報を、前記ブラックリストデータベースに登録することを特徴とする照合サーバである。
　（６）また、本発明は、（３）又は（４）記載の照合サーバにおいて、前記通信部は、外部からホワイトリスト登録要求を受信し、前記制御部に送信し、前記制御部は、前記通信部から送信されてきたホワイトリスト登録要求に含まれる正規のユーザの情報を、前記ホワイトリストデータベースに登録することを特徴とする照合サーバである。
　（７）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信するステップ、を含むことを特徴とする照合方法である。
　（８）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、悪意のハッカーの情報を保持するブラックリストデータベースと、正規のユーザの情報を保持するホワイトリストデータベースと、を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信するステップと、前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較するステップと、前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較するステップと、前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信するステップと、を含むことを特徴とする照合方法である。
　（９）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信する手順、を前記コンピュータに実行させることを特徴とするコンピュータプログラムである。
　（１０）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、悪意のハッカーの情報を保持するブラックリストデータベースと、正規のユーザの情報を保持するホワイトリストデータベースと、を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信する手順と、前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較する手順と、前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較する手順と、前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信する手順と、を前記コンピュータに実行させることを特徴とするコンピュータプログラムである。
　このように、本発明によれば、ログインヒストリーを用いて、正規のユーザであるか否かを判断する仕組みを構築しているので、正規のユーザではないと判断されたユーザによるアクセスをより効率的に検出することが可能となる。
本実施形態１において、悪意のハッカーが複数のサイトにアクセスする様子を示す説明図である。 本実施形態２において、正当なユーザ１８が複数のサイトにアクセスする様子を示す説明図である。 本実施形態１における照合サーバ２０の動作を表すフローチャートである。 本実施形態１における照合サーバ２０の動作を表すフローチャートの続きである。 本実施形態２における照合サーバ４０の動作を表すフローチャートである。 本実施形態２における照合サーバ４０の動作を表すフローチャートの続きである。 本実施形態１、２におけるログインヒストリーデータベース２６、４６に登録する内容の例を示す説明図である。 本実施形態１、２におけるホワイトリストデータベース４８、ブラックリストデータベース２８に登録する内容の例を示す説明図である。
　以下、本発明の好適な実施形態を図面に基づき説明する。
　実施形態１
　１－１．基本的構成
　本実施形態１は、複数のサイトが、自サイトにアクセスするユーザが正規のユーザであるか否かを、共通の照合サーバを利用して判断する例を説明する。図１には、このような複数のサイト（例えばショッピングモール）が、共通の照合サーバ２０を利用する例が示されている。
　図１において、ハッカー８は、悪意のあるハッカーであり、正規のユーザではないが、正規のユーザになりすます等の不正な手段を用いて、サイト１０ａ、１０ｂ、１０ｃ、１０ｄ等にアクセスしようとしている。
　ハッカー８は、インターネット等のネットワークを介して提供するためのサイト１０ａ、１０ｂ、１０ｃ、１０ｄに対して不正なアクセスを試みる。例えば、ハッカー８は、リスト型攻撃やなりすまし等の手法を用いて不正アクセスを試みる。
　なりすましは、他人になりすまして所定のサイトやサービスにアクセスして乗っ取る攻撃手法であり、近年は、いわゆるリスト型攻撃と呼ばれる手段が利用されることも多い。　　　
　リスト型攻撃は、各種のサイトやサービスに対して、そのユーザのアカウントを乗っ取る攻撃手法の一つである。例えば、別のサービスやシステムから流出したアカウント情報を用いてそのサービスやサイトにログインを試みる手法である。これは、同じアカウント名とパスワードとを複数のサイトやサービスに利用しているユーザが多いことを利用した攻撃手法であり、ある一つのサイトから流出したアカウント名（ＩＤ）やパスワードを用いて、他のサイトに侵入を試みるものである。同じアカウント名（ＩＤ）やパスワードを用いていれば、当該他のサイトにおいてユーザのアカウントが乗っ取られてしまう。リスト型攻撃は、パスワードリスト攻撃、リスト型アカウントハッキング、アカウントリスト攻撃等とも呼ばれる。
　１－２．動作
　図１の例では、ハッカー８は、正規のユーザのＩＤとパスワード（ＰＷ）を入手し、この情報を用いてリスト型攻撃を利用し、サイト１０ａ、１０ｂ、１０ｃ、１０ｄに対して不正なアクセスを試みる。
　照合サーバ２０は、各サイト１０ａ、１０ｂ、１０ｃ、１０ｄにおけるログインの情報（ログイン履歴）を各サイト１０（ａ～ｄ）から受信し、内部のログインヒストリーに記憶していく。本実施形態１において特徴的な構成は、この照合サーバ２０であり、各サイト１０（ａ～ｃ）からのログイン履歴を蓄積することによって、各サイト１０（ａ～ｃ）に代わって、アクセスしてきた者が正規ユーザとして怪しい（本人らしくない）か否かを判断するので、各サイト１０（ａ～ｃ）にとって便利である。
　図１に示すように、照合サーバ２０は、通信部２２と、制御部２４と、ログインヒストリーデータベース２６と、ブラックリストデータベース２８と、を備えている。ログインヒストリーデータベース２６は、外部の種々のサイトからの指示・依頼によって当該サイトへのログインのヒストリー（ログイン履歴）を記憶するデータベースである。ログイン履歴は、ログインが成功する場合も失敗する場合も含めて記憶する。
　通信部２２は、インターネット等のネットワークを介して外部の各種サイト等と通信を行うインターフェースであり、インターネット以外の通信手段を利用してもよく、いわゆる（携帯）電話網を利用する通信インターフェースであってもよい。通信部２２は、請求の範囲の通信部の好適な一例に相当する。
　制御部２４は、照合サーバ２０の動作を司る手段であり、具体的には、ログインヒストリーデータベース２６と、ブラックリストデータベース２８との記憶を制御し、また、これらデータベースに関する種々の動作を実行する。例えばＣＰＵとそのＣＰＵが実行するプログラムとから構成してよい。そのプログラムは、照合サーバ２０が実行する処理が記述されているプログラムである。また、そのプログラムは、請求の範囲のコンピュータプログラムの好適な一例に相当する。
　ログインヒストリーデータベース２６は、照合サーバ２０がサポートしているサイト１０（ａ～ｄ）からユーザ（または悪意のハッカー８）がログインした際のログインの情報（ログイン履歴（ログインヒストリー））を記憶するデータベースである。
　ブラックリストデータベース２８は、悪意のあるハッカー８であると判断された相手の情報を記憶するデータベースである。
　ログインヒストリーデータベース２６も、ブラックリストデータベース２８も、例えばハードディスク等の記憶手段で構成することができる。また、半導体記憶装置や、光学式の記憶装置を用いて構成してもよい。また、ログインヒストリーデータベース２６は、請求の範囲のログインヒストリーデータベースの好適な一例に相当する。また、ブラックリストデータベース２８も、請求の範囲のブラックリストデータベースの好適な一例に相当する。
　ログイン
　サイト１０ａは、ユーザがパスワードを定期的に変更しているサイト１０ａであり、その結果、ハッカー８は、そのサイト１０ａにとっては古いＩＤとパスワードとを使用することになり、ログインが失敗する。すると、サイト１０ａは、そのログインが失敗したというログイン失敗履歴を、照合サーバ２０に送信する。照合サーバ２０は、送信されてきたログイン失敗履歴（ログイン履歴（ログインヒストリー））を、その内部のログインヒストリーデータベース２６に記憶する。
　サイト１０ｂも、サイト１０ａと同様に、ユーザがパスワードを頻繁に更新しているサイト１０ｂであり、その結果、ハッカー８は、そのサイト１０ｂにとっては古いＩＤとパスワードとを使用することになり、ログインを失敗する。すると、サイト１０ｂは、サイト１０ａと同様に、そのログインが失敗したというログイン失敗履歴を、照合サーバ２０に送信する。照合サーバ２０は、送信されてきたログイン動作（ログイン履歴）を、その内部のログインヒストリーデータベース２６に記憶する。
　サイト１０ｃは、サイト１０ａ、１０ｂとは異なり、ユーザがパスワードを頻繁に更新しておらず、その結果、ハッカー８は、他所から流出した正規ユーザのＩＤやパスワードを流用してそのサイト１０ｃに適用して、ログインが成功してしまう。すると、サイト１０ｃにおいて、ハッカー８はログインを成功させてしまう。
　ログインが成功する／失敗するにかかわらず、各サイト１０（ａ～ｄ）はログインの情報を照合サーバ２０に送信する。サイト１０ｃも、ログインが成功したが、上記サイト１０ａ、１０ｂと同様に、ハッカー８によるログイン動作を照合サーバ２０に送信し、照合サーバ２０はログイン履歴をログインヒストリーデータベース２６に記憶していく。
　照合サーバ２０によるログイン履歴の検査
　照合サーバ２０は、送信されてくるログイン履歴がログイン失敗履歴であっても成功履歴であってもログインヒストリーデータベース２６に記憶していく。
　上で述べたように、サイト１０ｃでは、正しいＩＤとパスワードによって、本人認証が成功し、ログインが成功する。そして、サイト１０ｃは、そのログイン（成功）履歴を照合サーバ２０に送信する。
　ログイン履歴が送信されてきた場合の照合サーバ２０の動作が、図３、図４のフローチャートに記載されている。
　図３のステップＳ３－１において、まず、所定のサイト１０（ａ～ｃ）からログイン履歴が送信されてきた場合、通信部２２がこれを受信し、制御部２４に送る。
　ステップＳ３－２において、制御部２４は、送られてきたログイン履歴をログインヒストリーデータベース２６に順次格納していく。
　ステップＳ３－３において、制御部２４は、送られてきたログイン履歴を見て、そのログイン履歴が成功履歴であるか否か判断する。判断の結果、成功履歴であった場合は、ステップＳ３－４に移行し、失敗履歴であった場合は、終了する。
　ステップＳ３－４において、制御部２４は、送られてきたログイン履歴を、ブラックリストデータベース２８の登録内容と比較する。
　ステップＳ３－５において、上記ステップＳ３－４における比較の結果、同様のデータが登録されていた場合は、アクセスをしてきた者は、悪意のあるアクセス者であると判断できるので、ステップＳ３－６に移行する。一方、同様のデータが登録されていない場合は、図４のステップＳ４－１に移行する。
　ステップＳ３－６において、制御部２４は、悪意のあるハッカーである旨のメッセージを通信部２２を介して、ログイン履歴を送信してきたサイト１０（ａ～ｄ）に送信する。そして、処理を終了する。この結果、当該サイト１０（ａ～ｄ）は、ログイン拒否を実行することができ、悪意のあるアクセスを防止することができる。
　図１に示す例において、サイト１０ｃがログイン成功履歴を送信してきた場合、図３のステップＳ３－５において、同様のデータが、まだブラックリストデータベース２８には登録されていなかった場合の動作を説明する。この場合、ステップＳ３－５において、アクセスしてきた者と同様のデータがブラックリストデータベース２８に登録されていないので、図４のステップＳ４－１に移行する。
　図４のステップＳ４－１において、制御部２４は、送られてきたログイン履歴を送ったサイトのこれまでのログイン履歴をログインヒストリーデータベース２６から参照する。
　次に、ステップＳ４－２において、参照したこれまでのログイン履歴のログインの様子と、今回のログイン（成功）履歴とを比較し、ログイン動作の振る舞いがこれまでと同様か否かを判断する。判断の結果、これまでのログイン動作の振る舞いと異なる場合は、本人（正規のユーザ）らしくないと判断し、ステップＳ４－３に移行する。一方、判断の結果、これまでのログイン動作の振る舞いと同様である場合は、ログイン履歴の検査の動作を終了し、ログイン履歴の記憶動作を終了する。そして、次のログイン履歴が送信されてくるのを待つ状態となる。
　振る舞いの判断は、種々の手法を利用してよい。着目しているログイン動作を、ログインヒストリーデータベース２６中の内容と比較し、一致・類似するパラメータが多い場合を、振る舞いが同様である（共通する・類似する）と判断してもよい。また、多くのパラメータが一致・類似・共通すれば、大きく異なるパラメータが一つ見つかっても同様の振る舞いであると判断してもよい。また、パラメータの種類に応じて重みを設けてもよい。
　ステップＳ４－３において、制御部２４は、正規のユーザである本人らしくないことをサイト１０ｃに伝える。例えば、「本人らしくない」等のメッセージを当該サイト１０ｃに、通信部２２を介して送信する。
　このように、本実施形態の照合サーバ２０は、単にログイン履歴を記憶していくだけでなく、
　・送信されてきたログイン履歴から、同様の内容がブラックリストデータベース２８に登録されているか否か判断する。ブラックリストデータベース２８に登録されていた場合は、その旨を当該サイト１０に送信する。
　・さらに、ブラックリストデータベース２８に登録されていない場合でも、ログイン履歴の振る舞いを、ログインヒストリーデータベース２６中の当該サイト１０（ａ～ｃ）のログイン履歴と同様の振る舞いか否かを判断し、これまでと異なるログイン動作の振る舞いである場合は、その旨（例えば、「本人らしくない」等のメッセージ）を当該サイト１０ｃに送信している。
　このような動作によって、各サイト１０は、アクセスしてきた者が、正規のユーザであるか否か（悪意のアクセス者であるか否か）を効率的に判断することができ、便利である。
　サイト１０ｃにおける２要素認証の実行
　さて、図１に示す例では、サイト１０ｃが、ログインは成功したが、照合サーバ２０から「本人らしくない」とのメッセージを受信する（図４のステップＳ４－３）。サイト１０ｃは、これを受けて、例えば、２要素認証３０を実行することができる。
　２要素認証とは、異なる２要素に基づき認証を行う方式である。例えば、サイト１０ｃは、ワンタイムパスワードをログインしようとしている「ユーザ」の携帯電話に送信する。ユーザは自己の携帯電話からワンタイムパスワードを読み取り、サイト１０ｃに入力する。サイト１０ｃは、入力されたワンタイムパスワードが自己が送信したワンタイムパスワードと同一パスワードであれば、正当な本人であると判断する。
　いわゆる認証のための認証データには、「本人のみが知っていること（もの）（パスワード）」、「本人だけが所有するもの（キャッシュカード、携帯電話）」、「本人自身の特性（バイオメトリックデータ）」、等およそ３種の認証データが用いられるが、このうち異なる２種を使用して認証する方式は「２要素認証」と呼ばれる。上で説明した例では、最初の「パスワード」に加えて、新たに本人のみが所有する「携帯電話」が２番目の認証データとして用いられている。その電話番号の携帯電話は本人のみが所有するはずであることに基づくものである。本実施形態１では、このような２種の認証データを用いているが、他の２種の認証データを用いてもよい。
　図１に示す例では、この２要素認証３０の結果、本人ではないことが判明したので、ログインは拒否している（図１中、ログイン拒否３２）。このログイン拒否３２となった場合は、悪意のハッカー８であると認定し、ブラックリストデータベース２８に登録する。すなわち、サイト１０ｃは、照合サーバ２０に対してブラックリスト登録要求を送信する。
　照合サーバ２０によるブラックリストデータベース２８への登録
　照合サーバ２０は、送信されてくるブラックリスト登録要求を受信すると、その内容をブラックリストデータベース２８に登録する。
　具体的には、まず通信部２２がブラックリスト登録要求を受信する。
　次に、通信部２２がブラックリスト登録要求を制御部２４に送信する。
　制御部２４は、ブラックリスト登録要求を受信すると、その要求に従って、ハッカー８に付いての情報を、ブラックリストデータベース２８に登録する。このブラックリストデータベース２８の登録内容は、ハッカー８を識別することができればどのような登録内容でもよい。
　ログインヒストリーデータベース２６とブラックリストデータベース２８の活用
　図１の例によれば、ハッカー８は、サイト１０ｄにも、他のサイト１０ａ、１０ｂ、１０ｃと同様に、リスト型攻撃を実行する例が記載されている。
　サイト１０ｄも照合サーバ２０を利用しており、ログイン履歴を照合サーバ２０中のログインヒストリーデータベース２６に登録している。また、サイト１０ｄは、上記の通り本人ではないことが判明した場合は、ブラックリストデータベース２８に登録要求を行う。
　図１に示す例においては、サイト１０ｄは、サイト１０ａ、１０ｂ、１０ｃと同様に、まずログイン履歴を照合サーバ２０に送信している。この場合の照合サーバ２０の動作は、図３のフローチャートで説明した通りである。特に、図１に示したサイト１０ｄの場合は、ＩＤとパスワード（ＩＤ／ＰＷ）によるログインは成功したので、ステップＳ３－３、Ｓ３－４、Ｓ３－５と処理が進む。
　特に、図１に示したサイト１０ｄでは、ログインしてきたアクセス者が、既にブラックリストデータベース２８に登録されている。つまり、上述したように、ハッカー８は、サイト１０ｃが送信したブラックリスト登録要求（図１参照）によって、ブラックリストデータベース２８に登録されている。したがって、サイト１０ｄのログイン履歴に対して、照合サーバ２０は図３のステップＳ３－５において、同様のデータが存在することが判明する。その結果、ステップＳ３－６に移行し、ブラックリストに載っている悪意のハッカーであるとのメッセージが、制御部２４によって、（通信部２２を介して、）サイト１０ｄに送られる。
　サイト１０ｄは、このメッセージを受信することによって、アクセス者であるハッカー８が悪意のハッカー８であることを知ることができ、ログイン拒否を実行することができる。
　このように、本実施形態１において、サイト１０ｄは他のサイト１０（ａ～ｃ）が登録したログインヒストリーデータベース２６や、ブラックリストデータベース２８を利用することができ、不正なログインを行おうとする者を効率的に検出することができる。すなわち、他のサイト１０（ａ～ｃ）の記録した内容に基づき、アクセスしてきた者を正当なユーザか否かを判断することができる。
　ここで、記録する内容としては、さまざまな種類の内容に設定することができる。ログイン履歴として、アクセスしてきた者のＩＰアドレス、時刻、入力したＩＤやパスワードの入力速度、位置情報、アクセスしてきたデバイスの種別、利用しているブラウザの種類やバーション、ＯＳの名称やバージョン等、種々のパラメータを登録内容に含めることができる。これらの内、一部の情報のみを登録内容としてもよいし、さらに多くの他の種類の情報を含めてもよい。
　また、ログインヒストリーデータベース２６や、ブラックリストデータベース２８には、信頼度またはそれに準ずる指標となるデータを登録しておいてもよい。また例えば、上述した２要素認証３０の結果、悪意のハッカーであると判断してログイン拒否３２した場合、そのログイン履歴（ログインヒストリーデータベース２６内のログイン履歴）に、悪意のハッカーと判断したフラグを付加しておいてもよい。
　なお、本実施形態においては、各サイト１０（ａ～ｄ）が送信してきたデータに基づき、制御部２４が、ログインヒストリーデータベース２６中を検索し、また、ブラックリストデータベース２８を検索している。しかし、照合サーバ２０のユーザである各サイト１０（ａ～ｄ）が直接、ログインヒストリーデータベース２４や、ブラックリストデータベース２８に対してアクセスできるように構成してもよい。そして、それらの内容から、サイト１０（ａ～ｄ）自身が判断できるように構成してもよい。
　１－３．まとめ
　このように実施形態１によれば、ログイン履歴を蓄積していくログインヒストリーデータベース２６を備えた照合サーバ２０を利用すれば、ショッピングモール等のサイト１０（ａ～ｄ）は、アクセスしてきた者のアクセス履歴を参照することができるので、正当なユーザか否かを効率的に検出することができる。
　また、特に、照合サーバ２０は、ログインヒストリーデータベース２６の内容に基づき、
「本人らしくない」アクセスを検知することができる。したがって、各サイト１０（ａ～ｄ）が、ＩＤとパスワードだけでは判断しにくい「疑いのある」アクセスを知ることができる。特に、照合サーバ２０は、他サイト１０のアクセス履歴に基づき、「疑いのある」「本人らしくない」者を判断してくれるので、利用するサイト１０（ａ～ｄ）は「疑いのある」「本人らしくない」者を容易に知ることができ、上述したように、２要素認証等を実行することができる。
　例えば、このような動作を自サイトのみで実行しようとすれば、ユーザのアクセス履歴をある程度、自サイトで蓄積する必要がある。さらに、初めてそのサイト１０（ａ～ｄ）にアクセスするユーザに対してはアクセス履歴の蓄積がないので、判断が困難である。
　これに対して、本実施形態１によれば、他サイト１０（ａ～ｄ）が蓄積したアクセス履歴を利用した判断を照合サーバ２０から得られるので、初めてそのサイト１０（ａ～ｄ）にアクセスするユーザに対しても正規のユーザか否かを判断できる可能性がある。
　さらに、本実施形態１によれば、照合サーバ２０は、ブラックリストデータベース２８を構築（登録）しているので、当該ブラックリストデータベース２８中に該当する者が見いだされ場合は、すぐにログイン拒否をすることができ、サイトの安全性をより強力に担保することができる。
　ブラックリストデータベース２８に該当する者が登録されているか否かは、各サイトが照合サーバ２０に問いあわせを行って各サイト１０が判断してもよい。また、各サイト１０が図１に示すようにログイン履歴を登録しようとしたときに、照合サーバ２０の制御部２４が、別途ブラックリストデータベース２８の登録内容を確認するように構成してもよい。この場合、ブラックリストデータベース２８に該当する内容が登録されていた場合は、照合サーバ２０の制御部２４がその旨のメッセージをサイト１０に送信することも好ましい。
　実施形態２
　上述した実施形態１及び図１においては、ログインヒストリーデータベース２６と、ブラックリストデータベース２８とを備える照合サーバ２０について説明した。このような構成によって、ログイン履歴とブラックリストとを組み合わせて不正のアクセスを効率的に判断することができる。
　しかし、ログイン履歴をホワイトリストと組み合わせることも好適である。本実施形態２においては、このようにログイン履歴とホワイトリストと組み合わせる例について説明する。
　本実施形態２は、実施形態１と同様に、複数のサイトが、自サイトにアクセスするユーザが正規のユーザであるか否かを、共通の照合サーバ４０を利用して判断する例を説明する。図２には、このような複数のサイト（例えばショッピングモール）が、共通の照合サーバ４０を利用する例が示されている。
　図１において、ユーザ１８は、一般ユーザ又は正規の登録を行った正規ユーザである。ユーザ１８は、通常のログイン動作によって、サイト１０ａ、１０ｂ、１０ｃ、１０ｄ等にアクセスしようとしている。
　ユーザ１８は、インターネット等のネットワークを介して提供するためのサイト１０ａ、１０ｂ、１０ｃ、１０ｄに対して通常のログインを実行する。
　２－２．動作
　図２の例では、ユーザ１８は、初めてアクセスするユーザの場合は、そのサイトに登録してＩＤとパスワードを設定して入手する。既に登録している正規ユーザである場合は、その正規のユーザのＩＤとパスワード（ＰＷ）を用いて、サイト１０ａ、１０ｂ、１０ｃ、１０ｄに対してアクセス（ログイン）を実行する。
　照合サーバ４０は、各サイト１０ａ、１０ｂ、１０ｃ、１０ｄにおけるログインの情報（ログイン履歴）を各サイト１０（ａ～ｄ）から受信し、内部のログインヒストリーに記憶していく。本実施形態２においても、実施形態１と同様に、この照合サーバ４０は、各サイト１０（ａ～ｄ）からのログイン履歴を蓄積することによって、各サイト１０（ａ～ｄ）に代わって、アクセスしてきた者が正規ユーザとして怪しい（本人らしくない）か否かを判断するので、各サイト１０（ａ～ｄ）にとって便利である。ログインヒストリーに関する動作は、上述した実施形態１とほぼ同様である。
　図２に示すように、照合サーバ４０は、通信部４２と、制御部４４と、ログインヒストリーデータベース４６と、ホワイトリストデータベース４８と、を備えている。
　ログインヒストリーデータベース４６は、実施形態１（図１）のログインヒストリーデータベース２６と同様のデータベースである。通信部４２も、実施形態１（図１）の通信部２２と同様の通信インターフェースである。通信部４２も、請求の範囲の通信部の好適な一例に相当する。
　制御部４４は、照合サーバ４０の動作を司る手段であり、具体的には、ログインヒストリーデータベース４６と、ホワイトリストデータベース４８とに対する書き込み・読み出しを制御し、また、これらデータベースに関する種々の動作を実行する。例えばＣＰＵとそのＣＰＵが実行するプログラムとから構成してよい。そのプログラムは、照合サーバ４０が実行する処理が記述されているプログラムである。また、そのプログラムは、請求の範囲のコンピュータプログラムの好適な一例に相当する。
　ホワイトリストデータベース４８は、正規のユーザ１８であると判断された相手の情報を記憶するデータベースである。本実施形態２は、ログイン履歴を、このホワイトリストと連動させて効率的な判断を提供することができる照合サーバ４０に関する実施形態である。
　ホワイトリストデータベース４８は、ログインヒストリーデータベース４６と同様に、例えばハードディスク等の記憶手段で構成することができる。また、半導体記憶装置や、光学式の記憶装置を用いて構成してもよい。また、ログインヒストリーデータベース４６は、請求の範囲のログインヒストリーデータベースの好適な一例に相当する。また、ホワイトリストデータベース４８も、請求の範囲のホワイトリストデータベースの好適な一例に相当する。
　ログイン
　サイト１０ａは、ユーザ１８が正規ユーザとして登録し、正規にＩＤとパスワードとを取得しているサイト１０ａであり、ユーザ１８は、通常の手続きでログインが成功する。すると、サイト１０ａは、そのログインが成功したというログイン成功履歴を、照合サーバ４０に送信する。照合サーバ４０は、送信されてきたログイン成功履歴（ログイン履歴（ログインヒストリー））を、その内部のログインヒストリーデータベース４６に記憶する。
　サイト１０ｂも、サイト１０ａと同様に、ユーザ１８がパスワードを頻繁に更新しているサイト１０ｂであり、その結果、ユーザ１８は、そのサイト１０ｂにとって正しいＩＤとパスワードとを使用することにより、ログインを成功する。すると、サイト１０ｂは、サイト１０ａと同様に、そのログインが成功したというログイン成功履歴を、照合サーバ４０に送信する。照合サーバ４０は、送信されてきたログイン動作（ログイン履歴）を、その内部のログインヒストリーデータベース２６に記憶する。
　サイト１０ｃは、サイト１０ａ、１０ｂと同様に、ユーザ１８が正しいＩＤとパスワードを用いて正常にログイン可能である。その結果、サイト１０ｃもログインの情報を照合サーバ４０に送信する。サイト１０ｃも、ユーザ１８によるログイン動作を照合サーバ２０に送信し、照合サーバ４０はログイン履歴をログインヒストリーデータベース４６に登録していく。
　次に、ログイン履歴が送信されてきた照合サーバ４０の動作をフローチャートに基づき説明する。
　照合サーバ４０によるログイン履歴の検査
　照合サーバ４０は、送信されてくるログイン履歴がログイン失敗履歴であっても成功履歴であってもログインヒストリーデータベース４６に登録する。
　ログイン履歴が送信されてきた場合の照合サーバ４０の動作が、図５、図６のフローチャートに記載されている。
　図５のステップＳ５－１において、まず、所定のサイト１０（ａ～ｃ）からログイン履歴が送信されてきた場合、通信部４２がこれを受信し、制御部４４に送る。
　ステップＳ５－２において、制御部４４は、送られてきたログイン履歴をログインヒストリーデータベース４６に順次登録していく。
　ステップＳ５－３において、制御部４４は、送られてきたログイン履歴を見て、そのログイン履歴が成功履歴であるか否か判断する。判断の結果、成功履歴であった場合は、ステップＳ５－４に移行する。一方、失敗履歴であった場合は、照合サーバ４０の、そのログイン履歴に対する処理は終了し、次のログイン履歴の送信を待つ状態となる。図２に示す場合は、正規のユーザ１８による通常のログイン動作を表しているので、その場合は、ステップＳ５－４に処理が移行する。
　ステップＳ５－４において、制御部４４は、送られてきたログイン履歴を送ったサイト１０（ａ～ｃ）のこれまでのログイン履歴をログインヒストリーデータベース４６から参照する。
　ステップＳ５－５において、制御部４４は、参照したこれまでのログイン履歴のログインの様子と、今回のログイン（成功）履歴とを比較し、ログイン動作の振る舞いがこれまでと同様か否かを判断する。判断の結果、これまでのログイン動作の振る舞いと異なる場合は、本人（正規のユーザ）らしくない振る舞いと判断し、ステップＳ５－６に移行する。
　一方、判断の結果、これまでのログイン動作の振る舞いと同様である場合は、ログイン履歴の検査の動作を終了し、ログイン履歴の記憶動作を終了する。そして、次のログイン履歴が送信されてくるのを待つ状態となる。
　図２に示すサイト１０ｃの例の場合は、本人らしくないログインが行われている。例えばいつもとは異なる端末からログインした、又は、新しい位置（地理的位置）からログインした等、これまでとは異なるログインが行われている例である。このような場合は、上述したように、ステップＳ５－６に移行する。
　ステップＳ５－６において、制御部４４は、今回記憶したログイン履歴と、ホワイトデータベース４８の登録内容と比較する。そして、図６のステップＳ６－１に移行する。
　図６のステップＳ６－１において、上記ステップＳ５－６における比較の結果、同様のデータが登録されていた場合は、アクセスをしてきた者は、正当な権限を有するアクセス者であると判断し、ステップＳ６－２に移行する。一方、同様のデータが登録されていない場合は、図６のステップＳ６－３に移行する。
　ステップＳ６－２において、制御部４４は、例えば「ホワイトリストに載っている正規のユーザである」等のメッセージを、通信部４２を介して当該サイト（ａ～ｄ）に送信する。その後、当該ログイン履歴の処理を終了する。この結果、当該サイト１０（ａ～ｄ）は、本人らしくない振る舞いでアクセスが行われているが、正規のユーザ１８であることが確認済みであることを認識することができる。
　ステップＳ６－３において、制御部４４は、例えば「本人らしくない」等のメッセージを通信部４２を介して、ログイン履歴を送信してきたサイト１０（ａ～ｄ）に送信する。そして、処理を終了する。この結果、当該サイト１０（ａ～ｄ）は、ＩＤとパスワードは正しいが、本人らしくない振る舞いでアクセスが行われたことを認識することができる。
　このように、本実施形態の照合サーバ４０は、単にログイン履歴を記憶していくだけでなく、
　・送信されてきたログイン履歴を、これまでのログイン履歴と比較し、同様の振る舞いでない場合は、同様の内容がホワイトリストデータベース４８に登録されているか否か判断する。ホワイトリストデータベース４８に登録されていた場合は、その旨を当該サイト１０に送信する。
　・さらに、ホワイトリストデータベース４８に登録されていない場合は、ログイン履歴の振る舞いが、これまでと異なるログイン動作の振る舞いであるので、その旨（例えば、「本人らしくない」等のメッセージ）を当該サイト１０（上の例では１０ｃ）に送信している。
　このような動作によって、各サイト１０は、アクセスしてきた者が、正規のユーザであるか否か（悪意のアクセス者であるか否か）を効率的に判断することができ、便利である。
　サイト１０ｃにおける２要素認証の実行
　さて、図２に示す例では、サイト１０ｃが、ログインは成功したが、照合サーバ４０から「本人らしくない」とのメッセージを受信する（図６のステップＳ６－１）。サイト１０ｃは、これを受けて、例えば、２要素認証５０を実行することができる。２要素認証については、実施形態１で説明した通りである。
　図２に示す例では、この２要素認証５０の結果、本人であることが判明したので、ログインを許可している（図２中、ログイン許可５２）。このログイン許可５２となった場合は、正当な正規ユーザ１８であると認定し、サイト１０ｃは、ホワイトリスト登録要求を照合サーバ４０に対して送信する。
　照合サーバ４０によるホワイトリストデータベース４８への登録
　照合サーバ４０は、送信されてくるホワイトリスト登録要求を受信すると、その内容をホワイトリストデータベース４８に登録する。
　具体的には、まず通信部４２がホワイトリスト登録要求を受信する。
　次に、通信部４２がホワイトリスト登録要求を制御部４４に送信する。
　制御部４４は、ホワイトリスト登録要求を受信すると、その要求に従って、ユーザ１８に付いての情報を、ホワイトリストデータベース４８に登録する。このホワイトリストデータベース４８の登録内容は、ユーザ１８を識別することができればどのような登録内容でもよい。
　ログインヒストリーデータベース４６とホワイトリストデータベース４８の活用（サイト１０ｄの場合の動作）
　図２の例によれば、ユーザ１８は、サイト１０ｄにも、他のサイト１０ａ、１０ｂ、１０ｃと同様に、正規のＩＤとパスワードを用いて通常のログイン動作を実行する例が記載されている。
　サイト１０ｄも照合サーバ４０を利用しており、ログイン履歴を照合サーバ４０中のログインヒストリーデータベース４６に登録している。また、サイト１０ｄは、上記の通り２要素認証によって本人であることが判明した場合は、ホワイトリストデータベース４８に登録要求を行う。
　図２に示す例においては、サイト１０ｄは、サイト１０ａ、１０ｂ、１０ｃと同様に、まずログイン履歴を照合サーバ４０に送信している。この場合の照合サーバ４０の動作は、図５のフローチャートで説明した通りである。特に、図２に示したサイト１０ｄの場合は、ＩＤとパスワード（ＩＤ／ＰＷ）によるログインは成功したので、ステップＳ５－３、Ｓ５－４、Ｓ５－５と処理が進む。
　ステップＳ５－５において、ログイン履歴との比較で同様の振る舞いであれば、照合サーバ４０における処理は終了するが、ログイン履歴との比較で異なる振る舞いであった場合は、ステップＳ５－６においてホワイトリストデータベース４８との比較処理が実行される。
　図２に示したサイト１０ｄでは、ログインしてきたアクセス者が、既にホワイトリストデータベース４８に登録されている。つまり、上述したように、ユーザ１８は、サイト１０ｃが送信したホワイトリスト登録要求（図２参照）によって、ホワイトリストデータベース４８に登録されている。
　したがって、サイト１０ｄのログイン履歴に対して、照合サーバ４０は図６のステップＳ６－１において、同様のデータが存在するとの判断がなされる。その結果、ステップＳ６－２において、制御部４８は、例えば「ホワイトリストに登録されています」等のメッセージをサイト１０ｄに、通信部４２を介して送信する。このようにして、照合サーバ４０における処理が終了する。
　このように、本実施形態２において、サイト１０ｄは他のサイト１０（ａ～ｃ）が登録したログインヒストリーデータベース４６や、ホワイトリストデータベース４８を利用することができ、正規のユーザ１８であることを効率的に検出することができる。すなわち、他のサイト１０の記録した内容に基づき、アクセスしてきた者を正当なユーザか否かを判断することができる。
　ここで、記録した内容はさまざまな内容に設定することができる。ログイン履歴として、アクセスしてきた者のＩＰアドレス、時刻、入力したＩＤやパスワードの入力速度、位置情報、アクセスしてきたデバイスの種別、利用しているブラウザの種類やバーション、ＯＳの名称やバージョン等、種々のパラメータを登録内容に含めることができる。
　また、ログインヒストリーデータベース４６や、ホワイトリストデータベース４８には、信頼度またはそれに準ずる指標となるデータを登録しておいてもよい。また例えば、上述した２要素認証５０の結果、正規のユーザ１８であると判断してログイン許可５２した場合、そのログイン履歴（ログインヒストリーデータベース４６内のログイン履歴）に、正規のユーザ１８と判断したフラグを付加しておいてもよい。
　なお、本実施形態２においては、各サイト１０（ａ～ｄ）が送信してきたデータに基づき、制御部４４が、ログインヒストリーデータベース４６中を検索し、また、ホワイトリストデータベース４８を検索している。しかし、照合サーバ４０のユーザである各サイト１０（ａ～ｄ）が直接、ログインヒストリーデータベース２４や、ホワイトリストデータベース４８に対してアクセスできるように構成してもよい。そして、それらの内容から、サイト１０（ａ～ｄ）自身が判断できるように構成してもよい。
　２－３．まとめ
　このように実施形態２によれば、ログイン履歴を蓄積していくログインヒストリーデータベース４６を備えた照合サーバ４０を利用しているので、ショッピングモール等のサイト１０（ａ～ｄ）は、アクセスしてきた者のアクセス履歴を参照することができる。その結果、各サイト１０（ａ～ｄ）は、アクセスしてきた者を正当なユーザか否かを効率的に検出することができる。
　また、実施形態１と同様に、照合サーバ４０は、ログインヒストリーデータベース４６の内容に基づき、「本人らしくない」アクセスを検知することができる。したがって、各サイト１０（ａ～ｄ）が、ＩＤとパスワードだけでは判断しにくい「疑いのある」アクセスを知ることができる。特に、照合サーバ４０は、他サイト１０のアクセス履歴に基づき、「疑いのある」「本人らしくない」者を判断することができるので、利用するサイト１０（ａ～ｃ）は「疑いのある」「本人らしくない」者を容易に知ることができ、照合サーバの判断に基づき、適宜上述したように２要素認証等を実行することができる。
　例えば、このような動作を自サイトのみで実行しようとすれば、ユーザのアクセス履歴をある程度、自サイトで蓄積する必要がある。さらに、初めてそのサイト１０（ａ～ｄ）にアクセスするユーザに対してはアクセス履歴の蓄積がないので、判断が困難である。
　これに対して、本実施形態２によれば、他サイト１０（ａ～ｄ）が蓄積したアクセス履歴を利用した判断を照合サーバ４０から得られるので、初めてそのサイト１０（ａ～ｄ）にアクセスするユーザに対しても正規のユーザか否かを判断できる可能性がある。
　さらに、本実施形態２によれば、照合サーバ４０は、ホワイトリストデータベース４８を構築（登録）しているので、当該ホワイトリストデータベース４８中に該当する者が見いだされ場合は、サイト１０（ａ～ｄ）は（そのアクセス者が自サイトにとって初めてのアクセス者であったとしても）すぐにログイン許可をすることができる。
　ホワイトリストデータベース４８に該当する者が登録されているか否かは、各サイトが照合サーバ４０に問いあわせを行って各サイト４０が個別に判断してもよい。また、各サイト１０が図１に示すようにログイン履歴を登録しようとしたときに、照合サーバ４０の制御部４４が、別途ホワイトリストデータベース４８の登録内容を確認するように構成してもよい。この場合、ホワイトリストデータベース４８に該当する内容が登録されていた場合は、照合サーバ４０の制御部４４がその旨のメッセージをサイト１０に送信することも好ましい。
　実施形態１、２　まとめ
　（１）効果
　このように、実施形態１、２においては、ログインヒストリーデータベース２６、４６を構築し、それを複数のサイト１０間で共有（照合サーバ２０、４０で共有）することができるので、これまでとは異なる振る舞いのアクセスを効率的に検知することが可能である。
　また、特に、実施形態１においては、ブラックリストデータベース２８を構築しているので、悪意のハッカーであることを効率的に判断することができる。特に、その情報を、照合サーバ２０によって複数のサイトが共有することができるので、より効率的に不正アクセスを防止することができる。
　なお、悪意のハッカー８は、人間が自ら操作してアクセスを実行している場合もあれば、コンピュータ等が機械的にその正当なユーザになりすましてアクセスを実行している場合も含む。
　実施形態２において、ホワイトリストデータベース４８を構築しているので、一度至当なアクセス者であることが判明しているユーザーをその振る舞いにかかわらず判断することができる。特に、その情報を、照合サーバ４００によって複数のサイトが共有することができるので、より効率的に正当なユーザであることを効率的に判断することができる。
　（２）追加認証（リスクベース認証：Risk Based Authentication）の採用
　実施形態１、２においては、２要素認証を用いる例を説明したが、その他、種々の追加認証（リスクベース認証：Risk Based Authentication）を実行してもよい。
　（３）ログインヒストリーデータベース２６、４６の内容
　ログインヒストリーデータベース２６、４６は、様々なログイン情報を記録してよい。
　例えば、図７に示す様々な種別のデータをログイン毎に登録してもよい。
　図７には、ログインヒストリーデータベース２６、４６の登録例を示す説明図が示されている。この図においては、１回のログインで登録される情報の例が示されており、実際には、ログインの度にこれらの情報がログインヒストリーデータベース２６、４６に登録されてよい。
　同図に示すように、ログインヒストリーデータベース２６、４６に記録される内容は、例えば、５種類に分けられてよい。
　第１の種類の情報は、ユーザ情報であり、主としてＩＤとパスワードである。このユーザ情報は、動作の主体であるユーザを特定する情報である。
　このＩＤやパスワードとしては例えばハッシュ化されたＩＤ、および、ハッシュ化されたパスワードが記録されてもよい。これは、データの量をコンパクトにして比較演算等を容易にするためであり、また、個人を完全に特定されてしまうことを防止し、個人情報の漏洩の可能性を減少させるためである。
　第２の種類の情報は、端末情報であり、ユーザがサイト１０にアクセスした際に用いた端末の情報であり、用いられる端末の種類とＯＳの種類等が記録される。また、使用言語に関する情報も記録されてよい。
　第３の種類の情報は、ユーザが使用しているブラウザ等の情報である。このブラウザの情報も、使用する端末毎に記録される。使用するブラウザが複数種類ある場合も、複数のブラウザの情報が記録される。ここでは、「ブラウザ」と呼んでいるが、およそそのサイト１０にアクセスするための手段・プログラム全般を含めてよい。
　第４の種類の情報は、アクセスするユーザのＩＰアドレスである。このＩＰアドレスからユーザの位置を知ることができる。
　第５の種類の情報は、ページ遷移である。この情報は、図７に示すように、例えばリファラーＵＲＬ等であり、どこからそのサイトに遷移してきたかを示す。
　これらは、ログイン履歴の一例であり、より少ない情報をログイン履歴として登録するように構成してもよい。上の説明や図７では、種別が５種類の例を示したが、種別の数はより少なくてもよい（例えば１種でもよい）し、より多くてもよい。また、利用するサイトによって、登録されるログイン履歴の内容が異なっていてもよい。ログインヒストリーデータベース２６、４６中には、ログイン毎にこれらログイン履歴が登録され、蓄積されていく。
　（４）ホワイトリストデータベース４８と、ブラックリストデータベース２８の内容
　本実施形態１、２で構築するホワイトリストデータベース４８と、ブラックリストデータベース２８の内容は、種々のパラメータを含めてよい。
　両者は記録する内容としては同様であってもよいし、異なる内容であってもよい。
　図８には、正規のユーザであると判断されたユーザの情報を記録したホワイトリストデータベース４８の記録例と、正規のユーザになりすました悪意のあるハッカー情報を記録したブラックリストデータベース２８との記録例を示す説明図が示されている。
　同図に示すように、ホワイトリストデータベース４８（およびブラックリストデータベース２８）に記録される内容は、図７で示したログインヒストリーデータベース２６、４６の登録内容とほぼ同様であり、例えば、５種類に分けられる。
　第１の種類の情報～第４の種類の情報は、上で述べたとおりである。
　第５の種類の情報は、ページ遷移である。この情報も、図７に示すように、例えばリファラーＵＲＬ等である。特に、ホワイトリストデータベース４８やブラックリストデータベース２８では、その他に、Ｗｅｂサイト１０上でどのようなページを閲覧したかを示す情報も含めてよい。例えば、図８の例では、ホワイトリストデータベース４８の正規のユーザは、ログインした後、購入履歴ページで購入履歴を確認した後、ポイント確認ページを閲覧して利用可能なポイントを確認する～等の閲覧履歴を示す場合がある。また、ブラックリストデータベースの正規のユーザになりすました悪意のあるハッカーは、ログイン後、すぐにポイント交換ページに行き、ポイント交換をしようとする閲覧履歴である場合もある。このように、Ｗｅｂサイト１０で閲覧するページが、正規のユーザとなりすました悪意のハッカーとでは大きく異なることが、経験的に知られている。
　さらに、ページ遷移の情報においては、Ｗｅｂサイト１０に滞在した時間も記録されてよい。一般に正規のユーザと比較して、悪意のあるハッカーはＷｅｂサイト１０に滞在する時間が短いことが知られている。このような時間の情報としては、さらに、閲覧した各ページにおいて滞在した時間も記録しておいてよい。
　なお、悪意のあるハッカーは、人間である場合もあるし、規のユーザになりすました機械（コンピュータ）である場合もある。このようなコンピュータが正規のユーザになりすましている場合は、Ｗｅｂサイト１０全体の滞在時間も、各ページに滞在する時間も非常に短い場合が多く、滞在時間に基づいて人間と区別することができる場合もある。また、文字入力のスピードが異常に速いことでも人間と区別することが可能な場合もある。
　上記以外でも種々の情報を含めてもよい。例えば、文字入力のスピード等も含めてもよい。人間になりすました悪意のプログラムは、キー入力が異常に早いことが経験的に知られている。
　ここで説明した記録内容は、一例であり、もっと多種多様な種類の情報を記録してもよい。また、ここで説明した記録内容は、標準的な例を示したものであり、より少ない種類の情報を用いてホワイトリストデータベースやブラックリストデータベースを構成してもよい。また、上の説明や図８では、種別が５種類の例を示したが、種別の数はより少なくてもよいし、ブラックリストとホワイトリストで種別の数が異なっていてもよい。用途によっては１種類でも有用である。
　実施形態３．照合サーバ２０、４０の細部、関連技術
　（１）照合サーバ
　上で説明した照合サーバ２０、４０は、複数のサイト１０から利用され、ログイン履歴を蓄積していくサーバである。個別のサイト１０が自身でログイン履歴を蓄積するのに比べて、あるユーザ１８のログイン履歴をより多く蓄積することができるので、ログインの振る舞いから、当該アクセスがこれまでと同様の振る舞いか否かをより効率的に判断して、その結果を各サイト１０に通知することができる。
　その結果、各サイト１０は、ユーザ１８に対して、２要素認証３０等、正当性のさらなる認証を実行することができ、不正アクセスを効率的に検出することができる。
　さらに、各サイト１０は、正当性のさらなる認証を行った結果に基づき、ブラックリストデータベース２８や、ホワイトリストデータベース４８に登録要求できる。したがって、ブラックリストデータベース２８やホワイトデータベース４８に登録されれば、より確実にそのアクセス者が正当なユーザか否かを（照合サーバ２０、４０（の制御部２４，４４）が）判断することができ、その結果を各サイト１０に提供することが可能である。
　（２）ログインヒストリーデータベース
　本実施形態１、２に係るログインヒストリーデータベース２６、４６は、ログイン成功の場合も、ログイン失敗の場合もログイン履歴を蓄積していく。蓄積の方法は、種々の方法が採用可能であるが、当該ログ有限であるので、古いデータは適時削除していくことも好ましい。
　ログインヒストリーデータベース２６、４６は、上述した図７の情報を、ログイン毎に蓄積していけばよいが、同じユーザ１８のログイン成功履歴は、最新の所定個数だけ蓄積しておき、古い順に消去していくことも好ましい。
　このような動作は、制御部２４、４４が実行してよい。
　また、ログインヒストリーデータベース２６、４６は、ログイン失敗履歴についても、上述した図７の情報を、ログイン毎に蓄積していくが、これらはどの履歴が同じハッカー８であるか否かは判断がしにくい。そのため、ログイン失敗履歴については、まとめてその最大蓄積データ量を所定量に予め決めておき、その所定量の記憶容量を超えた場合に、古いログイン失敗履歴から削除していくことも好ましい。このような動作も、制御部２４、４４が実行してよい。
　又は、サイト毎に蓄積データ量をきめておいてもよい。各サイト１０に対して、ログイン失敗履歴を蓄積する最大蓄積データ量を決めておき、その量を超えた場合に古いログイン失敗履歴から削除していくことも好ましい。
　又は、蓄積時間を決めておき、その時間を超えた古いログイン履歴は削除していくように構成してもよい。
　このような動作も、制御部２４、４４が実行してよい。
　（３）ブラックリストデータベース２８と、ホワイトリストデータベース４８と、の共存
　上述した実施形態１、２では、ブラックリストデータベース２８を備えた照合サーバ２０と、ホワイトリストデータベース４８を備えた照合サーバ４０と、を説明したが、ブラックリストデータベース２８とホワイトリストデータベース４８とを共に備えた照合サーバを構成してもよい。
　そのような構成の場合は、
　・ブラックリストデータベース２８の登録内容との比較
　・ログイン履歴との比較
　・ホワイトリストデータベース４８の登録内容との比較
を順に実行するように構成してよい。
　具体的に言えば、図３のステップＳ３－５において「Ｎｏ」側に続けて、図５のステップＳ５－４に移行するように処理を行ってよい。
　第４．意義・効果
　近年では、悪意のある第三者が入手した一組のＩＤとパスワードを用いて、複数のサイト１０への不正アクセスが連続して行われる例が数多くみられる。このような連続した不正アクセスに対して、本実施形態における照合サーバ２０、４０は特に有用な対抗手段となり得る。また、本実施形態１、２では、単にユーザ１８のＩＤやパスワードだけではなく、ユーザ１８やハッカー８の動作のログイン履歴を記録してログインヒストリーデータベース２６、４６を構築して、それを複数のサイト間で共有する仕組みを提供している。したがって、単に１個のサイトが自前でユーザの履歴を管理することに比べて、より効率的にユーザ１８の認定、ハッカー８の検出を行うことが可能である。
　第５．他の変形例
　（１）上述した実施形態では、照合サーバ２０、４０は、各サイト１０からアクセスできる場所であれば、インターネット上のどこに位置してもよい。例えば、所定のサイト１０（例えば１０ａ）と同一のサーバ内に位置していてもよい。この場合は、照合サーバ＋サイトとの組み合わせた、照合サーバ付きサイトを構成することができる。
　（２）ホワイトリストデータベース４８中の同一のユーザの情報（レコード）の記録数を固定（例えばｎ個（ｎは自然数））して設定してもよいが、より少ない数でもよいし、また、多くてもかまわない。また、状況に応じて登録数を動的に調整するように構成してもよい。
　（３）上述した実施形態では、ブラックリストデータベース２８中のレコード数は制限を設けていないが、比較照合の演算速度等を考慮して、最大登録数に制限を設けてもよい。その場合は、例えば、古いレコードから削除していく等の処理を行ってもよい。
　（４）上述した実施形態では、ホワイトリストデータベース４８中のデータは実際のアクセスに基づき記録していったが、人為的に予め典型的な正規のデータを記録しておいてもよい。また、ブラックリストデータベース２８中に、予め判明している不正なアクセスの例を人為的に記憶させておいてもよい。
　（５）上述した実施形態では、ホワイトリストデータベース４８のデータは、新しいアクセスの度に更新され、古いデータは削除されていってよいが、人為的に固定したレコードを指定しておいてもよい。アクセスの頻度が低いユーザ１８を考慮したものである。
　（６）また、ホワイトリストデータベース４８、ブラックリストデータベース２８のレコードは人為的な手段、または他の手段で適宜チューニングを施してもよく、また、人の手によって、あまり重要でないレコードを削除してもよい。種々の人為的な作業を施してもよい。
　（７）上記実施形態では、ハッシュ化されたＩＤと、ハッシュ化されたパスワードとが、ホワイトリストデータベース４８、ブラックリストデータベース２８に記録されるが、ハッシュ化されないデータを用いてもよく、また所定の暗号化が施されたＩＤとパスワードを利用してもよい。
　また、本発明の実施形態について詳細に説明したが、前述した実施形態は、本発明を実施するにあたっての具体例を示したに過ぎない。本発明の技術的範囲は、前記実施形態に限定されるものではない。本発明は、その趣旨を逸脱しない範囲において種々の変更が可能であり、それらも本発明の技術的範囲に含まれる。
　８　ハッカー
　１０　１０ａ、１０ｂ、１０ｃ、１０ｄ　サイト
　１８　ユーザ
　２０、４０　照合サーバ
　２２、４２　通信部
　２４、４４　制御部
　２６、４６　ログインヒストリーデータベース
　２８　ブラックリストデータベース
　３０、５０　２要素認証（の実行）
　３２　ログイン拒否
　４８　ホワイトリストデータベース
　５２　ログイン許可

Claims (10)

  1. 　外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
    　前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
    　前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
    を備える照合サーバであって、
    　前記制御部は、
    　前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信することを特徴とする照合サーバ。
  2. 　請求項１記載の照合サーバにおいて、さらに、
    　悪意のハッカーの情報を保持するブラックリストデータベース、
    を備え、
    　前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信することを特徴とする照合サーバ。
  3. 　請求項１記載の照合サーバにおいて、さらに、
    　正規のユーザの情報を保持するホワイトリストデータベース、
    を備え、
    　前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信することを特徴とする照合サーバ。
  4. 　外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
    　前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
    　前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
    　悪意のハッカーの情報を保持するブラックリストデータベースと、
    　正規のユーザの情報を保持するホワイトリストデータベースと、
    を備える照合サーバであって、
    　前記制御部は、
    　前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信し、
    　前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、
    　前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、
    　前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信することを特徴とする照合サーバ。
  5. 　請求項２又は４記載の照合サーバにおいて、
    　前記通信部は、外部からブラックリスト登録要求を受信し、前記制御部に送信し、
    　前記制御部は、前記通信部から送信されてきたブラックリスト登録要求に含まれる悪意のハッカーの情報を、前記ブラックリストデータベースに登録することを特徴とする照合サーバ。
  6. 　請求項３又は４記載の照合サーバにおいて、
    　前記通信部は、外部からホワイトリスト登録要求を受信し、前記制御部に送信し、
    　前記制御部は、前記通信部から送信されてきたホワイトリスト登録要求に含まれる正規のユーザの情報を、前記ホワイトリストデータベースに登録することを特徴とする照合サーバ。
  7. 　外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
    　前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
    　前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
    を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、
    　前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信するステップ、
    　を含むことを特徴とする照合方法。
  8. 　外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
    　前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
    　前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
    　悪意のハッカーの情報を保持するブラックリストデータベースと、
    　正規のユーザの情報を保持するホワイトリストデータベースと、
    を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、
    　前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信するステップと、
    　前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較するステップと、
    　前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較するステップと、
    　前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信するステップと、
    　を含むことを特徴とする照合方法。
  9. 　外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
    　前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
    　前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
    を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、
    　前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信する手順、
    　を前記コンピュータに実行させることを特徴とするコンピュータプログラム。
  10. 　外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
    　前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
    　前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
    　悪意のハッカーの情報を保持するブラックリストデータベースと、
    　正規のユーザの情報を保持するホワイトリストデータベースと、
    を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、
    　前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信する手順と、
    　前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較する手順と、
    　前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較する手順と、
    　前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信する手順と、
    　を前記コンピュータに実行させることを特徴とするコンピュータプログラム。
    　
    　
PCT/JP2017/046313 2017-12-23 2017-12-25 照合サーバ、照合方法及びコンピュータプログラム WO2019123665A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017247098A JP6564841B2 (ja) 2017-12-23 2017-12-23 照合サーバ、照合方法及びコンピュータプログラム
JP2017-247098 2017-12-23

Publications (1)

Publication Number Publication Date
WO2019123665A1 true WO2019123665A1 (ja) 2019-06-27

Family

ID=66993193

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/046313 WO2019123665A1 (ja) 2017-12-23 2017-12-25 照合サーバ、照合方法及びコンピュータプログラム

Country Status (3)

Country Link
JP (1) JP6564841B2 (ja)
TW (1) TWI769240B (ja)
WO (1) WO2019123665A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111010402A (zh) * 2019-12-24 2020-04-14 深信服科技股份有限公司 账号登陆方法、装置、设备及计算机可读存储介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632348B (zh) * 2018-03-19 2020-02-18 阿里巴巴集团控股有限公司 一种业务校验方法和装置
JP2021101281A (ja) * 2019-12-24 2021-07-08 日本電気株式会社 生体認証システム、生体認証方法、及びコンピュータプログラム
TWI815715B (zh) * 2022-10-27 2023-09-11 英業達股份有限公司 利用伺服器日誌資料判斷伺服器狀態之判斷系統與判斷方法
TWI815722B (zh) * 2022-11-07 2023-09-11 英業達股份有限公司 利用伺服器日誌資料於測試前預先判斷伺服器狀態之判斷系統與判斷方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300720A1 (en) * 2008-05-30 2009-12-03 Microsoft Corporation Centralized account reputation
JP2010097467A (ja) * 2008-10-17 2010-04-30 Nomura Research Institute Ltd リスクベース認証システムおよびリスクベース認証方法
US20140007179A1 (en) * 2012-06-29 2014-01-02 Microsoft Corporation Identity risk score generation and implementation
JP2017076185A (ja) * 2015-10-13 2017-04-20 富士通株式会社 ネットワーク監視装置、ネットワーク監視方法、及びネットワーク監視プログラム
WO2017191719A1 (ja) * 2016-05-03 2017-11-09 株式会社カウリス サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム
WO2017208969A1 (ja) * 2016-06-01 2017-12-07 日本電信電話株式会社 検知装置、検知方法、検知システム、および検知プログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI621342B (zh) * 2016-06-08 2018-04-11 Chunghwa Telecom Co Ltd System for dynamically identifying Next Generation Network (NGN)/IP Multimedia Subsystem (IMS) Voice over Internet Protocol (VoIP) calls and system in which the calling and called users are accommodated in the same Talk Edge Controller (SBC) and method thereof

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300720A1 (en) * 2008-05-30 2009-12-03 Microsoft Corporation Centralized account reputation
JP2010097467A (ja) * 2008-10-17 2010-04-30 Nomura Research Institute Ltd リスクベース認証システムおよびリスクベース認証方法
US20140007179A1 (en) * 2012-06-29 2014-01-02 Microsoft Corporation Identity risk score generation and implementation
JP2017076185A (ja) * 2015-10-13 2017-04-20 富士通株式会社 ネットワーク監視装置、ネットワーク監視方法、及びネットワーク監視プログラム
WO2017191719A1 (ja) * 2016-05-03 2017-11-09 株式会社カウリス サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム
WO2017208969A1 (ja) * 2016-06-01 2017-12-07 日本電信電話株式会社 検知装置、検知方法、検知システム、および検知プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111010402A (zh) * 2019-12-24 2020-04-14 深信服科技股份有限公司 账号登陆方法、装置、设备及计算机可读存储介质

Also Published As

Publication number Publication date
JP2019114061A (ja) 2019-07-11
TWI769240B (zh) 2022-07-01
TW201928750A (zh) 2019-07-16
JP6564841B2 (ja) 2019-08-21

Similar Documents

Publication Publication Date Title
US9853983B2 (en) Preventing phishing attacks based on reputation of user locations
US11595417B2 (en) Systems and methods for mediating access to resources
CN109690547B (zh) 用于检测在线欺诈的系统和方法
US9900346B2 (en) Identification of and countermeasures against forged websites
US10104064B2 (en) Secure authentication systems and methods
WO2019123665A1 (ja) 照合サーバ、照合方法及びコンピュータプログラム
US8850567B1 (en) Unauthorized URL requests detection
TWI718291B (zh) 服務提供系統、服務提供方法、及電腦程式
US8312073B2 (en) CAPTCHA-free throttling
US20160197907A1 (en) Preventing unauthorized account access using compromised login credentials
US9015817B2 (en) Resilient and restorable dynamic device identification
US20050238174A1 (en) Method and system for secure communications over a public network
JP6506384B2 (ja) サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム
Wedman et al. An analytical study of web application session management mechanisms and HTTP session hijacking attacks
CN106850592A (zh) 一种信息处理方法、服务器及终端
JP6842951B2 (ja) 不正アクセス検出装置、プログラム及び方法
JP5743822B2 (ja) 情報漏洩防止装置及び制限情報生成装置
JP6506451B2 (ja) サービス提供システム、サービス提供方法、照合装置、照合方法及びコンピュータプログラム
JP4979127B2 (ja) アカウント情報漏洩防止サービスシステム
JP2021082342A (ja) 不正アクセス検出装置、プログラム及び方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17935495

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17935495

Country of ref document: EP

Kind code of ref document: A1