When receiving a registration request for a user, an information processing apparatus transmits an e-mail including an authentication uniform resource locator (URL) to an e-mail address included in the registration request. The apparatus receives an authentication request for the e-mail address that is transmitted by access to the URL. The apparatus determines whether the registration request is under attack. If the registration request is determined to be under attack, the apparatus performs control to request a transmitter of the authentication request to perform an operation to confirm whether the transmitter has made the registration request. If the registration request is determined to be not under attack, the apparatus performs control not to request the confirmation operation. The apparatus then authenticates the e-mail address corresponding to the authentication request and registers the user. If the confirmation operation is requested, the apparatus does not register the user based on the confirmation operation.

BACKGROUND

Field

The present disclosure relates to a user registration technique.

Description of the Related Art

In recent years, various services have become available through connection to the Internet.

When starting to use any of these services, a user makes a registration request by entering information such as the user's name and e-mail address. To verify the validity of the e-mail address entered at this time, it is common to transmit an identity verification e-mail to the e-mail address. Japanese Patent Application Laid-Open No. 2004-192193 discusses a technique for verifying the validity of an e-mail address, by which an identity verification e-mail including a link for authentication is transmitted to the e-mail address and the recipient of the e-mail opens the link. When the validity of the e-mail address is verified, the user is officially registered with the service.

Meanwhile, there are attackers who make a user registration request using an e-mail address obtained in some way. Under such an attack, if the owner of the e-mail address opens the link in the identity verification e-mail by mistake, the user is officially registered with the service, so that the attacker can pretend to be the owner of the e-mail address and use the service.

SUMMARY

The present disclosure is directed to reducing the risk of false user registration in a system in which user registration is made using an e-mail address.

According to an aspect of the present disclosure, an information processing apparatus includes a first reception unit configured to receive a registration request for a user, a transmission unit configured to transmit an e-mail including an authentication uniform resource locator (URL) to an e-mail address included in the registration request, a second reception unit configured to receive an authentication request for the e-mail address, the authentication request being transmitted by access to the authentication URL, an attack determination unit configured to determine whether the registration request received by the first reception unit is under attack, a request control unit configured to, in a case where the attack determination unit determines that the registration request received by the first reception unit is under attack, perform control to request a transmitter of the authentication request received by the second reception unit to perform a confirmation operation to confirm whether the transmitter has made the registration request and, in a case where the attack determination unit determines that the registration request received by the first reception unit is not under attack, perform control not to request the confirmation operation, and a registration unit configured to authenticate the e-mail address corresponding to the authentication request received by the second reception unit and register the user corresponding to the registration request including the e-mail address. In a case where the request control unit requests the confirmation operation, the registration unit does not register the user based on a result of the confirmation operation.

DESCRIPTION OF THE EMBODIMENTS

Configurations illustrated in the following exemplary embodiments are merely examples, and the present disclosure is not limited to the illustrated configurations.

FIG.1is a schematic diagram illustrating an example of a configuration of an authentication system according to a first exemplary embodiment. The authentication system includes an authentication server102, a resource server103, and a user terminal104.

The authentication server102, the resource server103, and the user terminal104are communicably connected to each other via a network101.

The authentication server102performs user authentication. The authentication server102receives a user authentication request from the user terminal104. The authentication request includes authentication information. In the present exemplary embodiment, a user identification (ID) and identity verification information such as a password will be referred to as authentication information. The authentication server102authenticates a user by verifying the authentication information of the user against user information registered in the authentication server102. The authentication server102is an example of an information processing apparatus that receives a user registration request from the user terminal104and registers the user based on the received registration request. Characteristic processing in the present exemplary embodiment is mainly performed by the authentication server102.

The resource server103possesses resources. In the present exemplary embodiment, the resources refer to all types of data and processes available via the network101(the Internet). The user terminal104can use the resources provided by the resource server103only if the user authentication by the authentication server102succeeds.

The user terminal104is a personal computer (PC), a mobile terminal, or the like. The user terminal104transmits a user registration request or a user authentication request to the authentication server102.

FIG.1illustrates an example of a configuration of the authentication system according to the present exemplary embodiment. The functions of the server apparatuses included in the authentication system may be distributed and arranged in different computers, or may converge into the same computer. For example, the authentication server102and the resource server103may be included in the same computer. The server apparatuses are not limited to physical server apparatuses and may be virtual server apparatuses.

FIG.2is a block diagram illustrating an example of a hardware configuration of the authentication server102according to the present exemplary embodiment. Each of the resource server103and the user terminal104can be implemented by a hardware configuration similar to that of the authentication server102. The authentication server102, the resource server103, and the user terminal104may not necessarily have the same configuration.

The authentication server102includes a central processing unit (CPU)201, a random access memory (RAM)202, a network interface (I/F)203, an external storage device204, a display205, a keyboard206, and a mouse207. These components are connected to each other via a bus208.

The CPU201controls the entire operation of the authentication server102. The CPU201executes programs stored in the external storage device204or the like, thereby implementing various functions of the authentication server102and processing in the flowcharts to be described below. The RAM202is a volatile memory that temporarily stores data to be used, and functions as a work area that is used by the CPU201to load data when executing programs.

The network I/F203connects to the network101under control of the CPU201to transmit and receive data to and from other apparatuses on the network101. The external storage device204is a non-volatile memory such as a magnetic disk or a flash memory and stores programs and various types of information. The display205is an example of a display unit that displays processing results and the like under control of the CPU201. The keyboard206and the mouse207are examples of an input unit that outputs, to the CPU201, input information based on a user's input operation. The user can perform an input operation using the keyboard206and the mouse207on the displayed contents on the display205. The input unit may be a touch panel.

FIG.3is a block diagram illustrating an example of a functional configuration of the authentication server102according to the present exemplary embodiment. The CPU201executes programs stored in the external storage device204or the like, whereby the authentication server102functions as a user communication unit301, a user registration unit302, an attack determination unit303, an additional operation request unit304, an e-mail address authentication unit305, and a user deletion unit306. The authentication server102also secures a storage area for storing a user information storing unit307and a history information storing unit308, in the external storage device204or the like.

The user communication unit301communicates with the user terminal104to exchange various kinds of information with the user terminal104. The user communication unit301receives a user registration request from the user terminal104. If the received registration request is a request to register an unregistered user, an e-mail address included in the registration request is registered in the user information storing unit307, as information of the user in a provisionally registered state. The user communication unit301then transmits an identity verification e-mail to the e-mail address of the user in the provisionally registered state. The identity verification e-mail includes a uniform resource locator (URL) including information (a provisional registration ID) with which the user in the provisionally registered state can be uniquely identified. The user terminal104accesses the URL in response to the recipient of the identity verification e-mail performing an operation of clicking or touching the URL.

The user terminal104transmits an e-mail address authentication request by accessing the URL. The user communication unit301receives the e-mail address authentication request from the user terminal104.

The user registration unit302registers the user in response to the user registration request received by the user communication unit301. If the registration request received by the user communication unit301is a request to register an unregistered user, the user registration unit302registers the e-mail address included in the registration request into the user information storing unit307, as the information of the user in the provisionally registered state. Then, if the e-mail address is authenticated by the e-mail address authentication unit305, the user registration unit302newly registers the user corresponding to the e-mail address.

The attack determination unit303determines whether an attack occurs on a user registration request that is made to the authentication system. In the present exemplary embodiment, the attack determination unit303determines whether a user registration request is under attack. In the present exemplary embodiment, the attack refers to a situation where an attacker makes user registration requests using an e-mail address list obtained in some way. In general, a user registration request is made to register a new user, and thus the registration of an unregistered user is requested. The frequency of making a registration request for an existing user (an already registered user) is low because the request is made in a rare case where, for example, the user has forgotten about the registration made in the past. On the other hand, if an attacker makes registration requests using an obtained e-mail address list, the attacker does not know in advance whether the users have already been registered in the authentication system and thus the registration requests from the attacker include a certain number of registration requests for existing users. To address this, in the present exemplary embodiment, if an increase in the proportion of registration requests for existing users is detected, the attack determination unit303determines that the attack occurs.

If the attack determination unit303determines that the attack occurs, the additional operation request unit304requests the recipient of the identity verification e-mail to perform a confirmation operation to confirm whether the recipient himself or herself has made the registration request, in addition to the operation of clicking or touching the URL in the identity verification e-mail.

Upon receipt of the e-mail address authentication request by the user communication unit301, the e-mail address authentication unit305authenticates the e-mail address.

If a user deletion request is returned as a result of the confirmation operation requested by the additional operation request unit304, the user deletion unit306deletes, from the user information storing unit307, the information of the user in the provisionally registered state.

FIG.4illustrates information stored in the user information storing unit307. The user information storing unit307is a data table that stores the information included in the user registration request. A user ID field401stores user IDs with which users can be uniquely identified in the authentication system. A password field402stores the users' passwords. An e-mail address field403stores the users' e-mail addresses.

A user name field404stores the users' registration names.

A provisional registration ID field405stores the provisional registration IDs of the users if applicable. The record in which a value of the provisional registration ID is stored indicates that the user is in the provisionally registered state. A registration request date and time field406stores the dates and times when the user registration requests are received. An IP address field407stores the IP addresses of the user terminals104that are the transmitters of the user registration requests. A browser field408stores the types of browsers on the user terminals104that are the transmitters of the user registration requests. The user information storing unit307stores the records each including the user ID, the password, the e-mail address, the user name, the registration request date and time, the IP address, and the type of browser. The provisional registration IDs are included only in the records in the provisionally registered state.

FIG.5illustrates information stored in the history information storing unit308. The history information storing unit308is a data table that stores history information about the received user registration requests. A registration request date and time field501stores the dates and times when the user registration requests are received. An existing user field502stores information indicating whether the users corresponding to the registration requests are existing users (previously registered users) or unregistered users. In the case of an existing user, the value “TRUE” is stored in the existing user field502. In the case of an unregistered user, the value “FALSE” is stored in the existing user field502. Each time a user registration request is received, a record is added to and stored in the history information storing unit308.

FIG.6is a flowchart illustrating processing performed by the authentication server102according to the present exemplary embodiment in the case of receiving a user registration request.

In step S601, the CPU201receives a user registration request from the user terminal104.

The user registration request received at this time includes information such as a user name, an e-mail address, and a password. The CPU201also acquires the IP address of the user terminal104, which is the transmitter of the user registration request, and the type of browser on the user terminal104.

In step S602, the CPU201determines whether the user registration request received in step S601is a request to register an unregistered user. More specifically, the CPU201searches the records stored in the user information storing unit307to find a record including the e-mail address received in step S601. As a result of the search, if there is no record including the e-mail address, the CPU201determines that the user registration request is a request to register an unregistered user. If there is a record including the e-mail address and it is found that the user in the record is the same as the user of which registration is requested, the CPU201determines that the user registration request is a request to register an existing user. If the CPU201determines that the user registration request is a request to register an unregistered user (YES in step S602), the processing proceeds to step S603. If the CPU201determines that the user registration request is a request to register an existing user (NO in step S602), the processing proceeds to step S606.

In step S603, the CPU201stores the information received and acquired in step S601into the user information storing unit307. The user ID field401and the provisional registration ID field405respectively store generated unique values. The password field402, the e-mail address field403, the user name field404, the IP address field407, and the browser field408respectively stores the corresponding information received or acquired in step S601. The registration request date and time field406stores the current date and time. In this manner, the CPU201provisionally registers the information of the user in response to the user registration request received in step S601.

In step S604, the CPU201transmits an identity verification e-mail to the e-mail address received in step S601.FIG.8Aillustrates an example of the identity verification e-mail transmitted in step S604.

The identity verification e-mail illustrated inFIG.8Ais displayed on the display205of the user terminal104. The CPU201generates an URL801including the provisional registration ID generated in step S603and the address of the authentication server102, and includes the URL801into the identity verification e-mail. The user terminal104transmits an e-mail address authentication request to the authentication server102in response to the operation of clicking or touching the URL801in the identity verification e-mail. The URL801is an example of an authentication URL.

In step S605, the CPU201records information indicating the receipt of the registration request for the unregistered user, into the history information storing unit308. The registration request date and time field501stores the current date and time. The existing user field502stores the value “FALSE”. The processing in the flowchart is then ended.

In step S606, the CPU201records information indicating the receipt of the registration request for the existing user, into the history information storing unit308. The registration request date and time field501stores the current date and time. The existing user field502stores the value “TRUE”. The processing in the flowchart is then ended.

FIG.7is a flowchart illustrating processing performed by the authentication server102according to the present exemplary embodiment in the case of receiving an e-mail address authentication request.

In step S701, the CPU201receives an e-mail address authentication request from the user terminal104.FIG.8Aillustrates an example of the e-mail address authentication request that is transmitted by the user terminal104accessing the URL801.

The e-mail address authentication request received at this time includes the provisional registration ID in the URL801.

In step S702, the CPU201determines whether an attack occurs at the time of the registration request for the user (the target user) corresponding to the provisional registration ID received in step S701. More specifically, the CPU201acquires, from the user information storing unit307, the record including the provisional registration ID received in step S701and acquires, from the acquired record, the registration request date and time in the registration request date and time field406.

The CPU201then acquires, from the history information storing unit308, the records that are made around (e.g., ten minutes before and after) the registration request date and time and determines whether the proportion of registration requests for existing users in all the acquired records is greater than or equal to a threshold. More specifically, the CPU201refers to the existing user field502to calculate the proportion of records with “TRUE” in all the acquired records and determines whether the calculated value is greater than or equal to the threshold (e.g., 10%). If the calculated value is greater than or equal to the threshold, the CPU201determines that an attack occurs at the time of the registration request for the target user (YES in step S702), and the processing proceeds to step S703. If the calculated value is less than the threshold, the CPU201determines that an attack does not occur at the time of the registration request for the target user (NO in step S702), the processing proceeds to step S707.

In step S703, the CPU201requests the user terminal104, which is the transmitter of the authentication request received in step S701, to perform a confirmation operation to confirm whether the user himself or herself has made the registration request.FIG.8Billustrates an example of a screen for requesting the confirmation operation. The screen illustrated inFIG.8Bis displayed on the display205of the user terminal104. In the example ofFIG.8B, access information802at the time of the registration request for the user is displayed. The CPU201acquires, from the user information storing unit307, the record including the provisional registration ID received in step S701and generates the access information802using the values of the IP address field407, the browser field408, and the registration request date and time field406in the acquired record. The CPU201displays the access information802on the display205of the user terminal104. The CPU201presents the access information802to the recipient of the identity verification e-mail to prompt the recipient to confirm whether the recipient himself or herself has made the registration request. On the screen illustrated inFIG.8B, a checkbox803for confirming that the user himself or herself has made the registration request, a continue button804for issuing an instruction to continue the registration processing, and a user deletion button805for issuing an instruction to delete the information of the user corresponding to the registration request are provided. The user terminal104receives an operation performed on the screen illustrated inFIG.8Bvia the mouse207of the user terminal104, and transmits a result of the operation to the authentication server102.

In step S704, the CPU201receives the operation result from the user terminal104. In the example ofFIG.8B, if the checkbox803is checked and the continue button804is pressed, the CPU201determines that an instruction is issued to continue the user registration processing. If the user deletion button805is pressed, the CPU201stops the user registration processing and determines that an instruction is issued to delete the information of the user.

In step S705, the CPU201determines whether an instruction is issued to delete the information of the user, based on the operation result received in step S704. If the CPU201determines that an instruction is issued to delete the information of the user (YES in step S705), the processing proceeds to step S706. If the CPU201determines that an instruction is issued to continue the user registration processing (NO in step S705), the processing proceeds to step S707.

In step S706, the CPU201deletes the information of the user in the provisionally registered state without newly registering the user in the provisionally registered state. More specifically, the CPU201deletes, from the user information storing unit307, the record including the provisional registration ID received in step S701. Then, the processing in the flowchart is ended.

In step S707, the CPU201authenticates the e-mail address of which authentication is requested in step S701, and newly registers the user in the provisionally registered state. More specifically, the CPU201deletes the value of the provisional registration ID field405in the record including the provisional registration ID received in step S701. The CPU201also notifies the user terminal104, which is the transmitter of the e-mail address authentication request, that the authentication of the e-mail address is completed.

FIG.8Cillustrates an example of a screen for providing the notification that the authentication of the e-mail address is completed. The screen illustrated inFIG.8Cis displayed on the display205of the user terminal104. The processing in the flowchart is then ended.

In the flowchart ofFIG.7, if the CPU201determines that an attack occurs at the time of the registration request for the user, the CPU201performs control to request the recipient of the identity verification e-mail to perform a confirmation operation to confirm whether the recipient himself or herself has made the registration request. Then, as a result of the operation, if the recipient confirms that the recipient himself or herself has made the registration request and issues an instruction to continue the user registration processing, the CPU201authenticates the e-mail address and newly registers the user. As a result of the operation, if the recipient issues an instruction to delete the information of the user, the CPU201stops the user registration processing and deletes the information of the user in the provisionally registered state. On the other hand, if the CPU201determines that an attack does not occur at the time of the registration request, the CPU201performs control not to request the above-described confirmation operation, and authenticates the e-mail address and newly registers the user. In this manner, the CPU201performs request control processing to control the request for the above-described confirmation operation.

In step S702inFIG.7, the CPU201determines whether an attack occurs at the time of the registration request, using the registration request date and time in the history information stored in the history information storing unit308. However, the present exemplary embodiment is not limited to the method using the registration request date and time. In some embodiments, the CPU201acquires, from the history information storing unit308, the records stored within a predetermined period of time (e.g., ten minutes) from the current date and time, and determines whether the proportion of registration requests for existing users in all the acquired records is greater than or equal to a threshold. If the proportion is greater than or equal to the threshold, the CPU201sets an attack flag to ON, and if the proportion is smaller than the threshold, the CPU201sets the attack flag to OFF. The CPU201regularly performs attack flag setting processing as described above. In step S702, based on whether the attack flag is set to ON, the CPU201determines whether an attack occurs at the time of the registration request. Because there is a time lag between the occurrence of an attack and the switching of the attack flag from OFF to ON, the CPU201may determine that the attack flag is set to ON for the registration request that is made slightly earlier than the timing at which the attack flag is switched from OFF to ON.

In step S702inFIG.7, the CPU201determines whether an attack occurs at the time of the registration request, based on the history information stored in the history information storing unit308. However, the present exemplary embodiment is not limited to the method using the history information stored in the history information storing unit308. The CPU201may regularly perform attack detection using another method and separately store the date and time when an attack is detected. The CPU201may then determine the presence or absence of occurrence of an attack at the time of the registration request, by checking the date and time in the registration request date and time field406that is acquired from the record including the provisional registration ID against information about the date and time when an attack is detected.

As described above, according to the present exemplary embodiment, regarding a new user registration request that is under attack, the owner of the e-mail address included in the new registration request is requested to perform a confirmation operation to confirm whether the owner himself or herself has made the registration request. Therefore, it is possible to reduce the risk of the user being newly registered due to the owner of the e-mail address opening the link in the identity verification e-mail by mistake. The above-described confirmation operation is requested in a case where an attack occurs, and is not requested in a case where no attack occurs. This suppresses the operation burden on the user.

In the first exemplary embodiment, the example has been described where, if an attack occurs at the time of a user registration request, the owner of the e-mail address is requested to perform a confirmation operation to confirm whether the owner himself or herself has made the registration request. However, if there is a high possibility that the owner of the e-mail address and the requester of the user registration request are the same, the above-described confirmation operation may be omitted. Thus, in a second exemplary embodiment, if it can be determined that the owner of the e-mail address and the requester of the user registration request are the same, the user registration processing is continued without the above-described confirmation operation. In the present exemplary embodiment, components and steps having the same functions as those in the first exemplary embodiment are given the same reference numerals and a description thereof will be omitted.

FIG.9is a block diagram illustrating an example of a functional configuration of the authentication server102according to the present exemplary embodiment. The functional configuration according to the present exemplary embodiment is different from the functional configuration according to the first exemplary embodiment in that an identity determination unit901is added. The identity determination unit901determines whether the transmitter of a registration request for an unregistered user and the transmitter of an e-mail address authentication request are the same.

FIG.10is a flowchart illustrating processing performed by the authentication server102according to the present exemplary embodiment in the case of receiving an e-mail address authentication request.

In step S701, the CPU201receives an e-mail address authentication request from the user terminal104. At this time, the CPU201acquires information such as the IP address of the user terminal104, which is the transmitter of the e-mail address authentication request, and the type of browser on the user terminal104.

In step S1001, the CPU201determines whether the transmitter of the registration request for the unregistered user and the transmitter of the e-mail address authentication request are the same. More specifically, the CPU201acquires, from the user information storing unit307, the record including the provisional registration ID received in step S701and acquires the values of the IP address field407and the browser field408from the acquired record. The CPU201then determines whether the acquired IP address and browser type are the same as those acquired in step S701. If the CPU201determines that the IP address and browser type are the same as those acquired in step S701(YES in step S1001), the CPU201determines that the transmitter of the registration request for the unregistered user and the transmitter of the e-mail address authentication request are the same. If the CPU201determines that the transmitter of the registration request for the unregistered user and the transmitter of the e-mail address authentication request are the same, the processing proceeds to step S707. In this manner, if it can be determined that the owner of the e-mail address is the same as the requester of the registration request for the unregistered user, the CPU201authenticates the e-mail address without requesting the owner of the e-mail address to perform a confirmation operation to confirm whether the owner of the e-mail address himself or herself has made the registration request. If the CPU201determines that the transmitter of the registration request for the unregistered user is different from the transmitter of the e-mail address authentication request (NO in step S1001), the processing proceeds to step S702. In this case, there is a possibility that the user registration request is made by an attacker, and thus the CPU201requests the owner of the e-mail address to perform a confirmation operation to confirm whether the owner of the e-mail address himself or herself has made the registration request. The method for determining whether the owner of the e-mail address is the same as the requester of the registration request for an unregistered user is not limited thereto, and a method using cookies may be used. In this case, the CPU201may store cookies in the browser of the user terminal104and determine whether the value of a cookie that is transmitted at the time of transmission of the registration request for an unregistered user is the same as the value of a cookie that is transmitted at the time of transmission of the e-mail address authentication request. The subsequent processing is similar to that in the first exemplary embodiment.

As described above, according to the present exemplary embodiment, if it can be determined that the requester of a new user registration request and the owner of an e-mail address included in the request are the same, it is possible to omit a confirmation operation that is performed by the owner of the e-mail address to confirm whether the owner of the e-mail address himself or herself has made the new registration request. This reduces the operation burden on the user and decreases the complication of the processing procedure.

Other Embodiments

This application claims the benefit of Japanese Patent Application No. 2022-197983, filed Dec. 12, 2022, which is hereby incorporated by reference herein in its entirety.