JP2011123811A - Authentication system, detection device, terminal and authentication method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To obtain an authentication system that can reduce the frequency of failure to obtain software tokens. <P>SOLUTION: The authentication system, which performs authentication using authentication passwords including a first password as a fixed password and a second password as a variable password, includes: a terminal 1 which transmits a predetermined authentication request and a token obtaining request; an authentication server 4 which performs authentication in response to the received authentication request; a token obtaining server 6 which return a token in response to the received token obtaining request; and a detection device 8 which relays communications between the terminal 1 and the token obtaining server 6, wherein the detection device 8 includes a state detection part 82 which determines whether the token obtaining request received from the terminal should be transferred to the token obtaining server or not on the basis of the congestion state of the token obtaining server 6 received from the token obtaining server 6. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to an authentication system for authenticating a user.

  Conventionally, when remotely connecting to an in-house system from outside the company using a terminal such as a notebook PC or a mobile phone, the in-house system authentication server performs user authentication and confirms the validity of the user before connecting to the terminal. . At this time, in order to improve security in authentication, a method of generating a one-time password by combining a plurality of elements and performing authentication has become mainstream. For example, in a method using a hard token typified by RSA SecurID, a one-time password is determined by combining characters shown in the hard token and a fixed password, and authentication is performed using the password. However, this method has a problem that if a hard token is lost, it becomes impossible to connect from outside the company. Further, since hard tokens are distributed to all users, there is a problem that costs related to management operation of each hard token increase.

  In Patent Document 1 below, as a method for solving these problems, a software token is installed in a terminal, and a one-time password combining a token value displayed in the terminal and a fixed password is given to an authentication server for authentication. The technology of the authentication system which performs is disclosed.

  Specifically, when the user inputs a user ID to the terminal, the terminal first transmits the user ID to the authentication server. The authentication server generates a matrix table corresponding to the token, encrypts it, and returns it to the terminal. The terminal decrypts and displays the encrypted matrix table. The user who uses the terminal creates a combination of numbers from the matrix table based on the pattern registration rules that the user defines and registers in the authentication system in advance, and the terminal sends these numbers to the authentication server as a password. To do. The authentication server performs authentication by verifying the password from the matrix table, the user ID, and the pattern registration rule.

JP 2007-264839 A

  However, in the above conventional authentication system, encryption is accompanied by acquisition of a matrix table and a reply to the terminal, so that much traffic and CPU load are required for acquiring the matrix table for one user. Therefore, there is a problem that when the number of users increases, the CPU load increases as compared with a normal Web system, and the occurrence frequency of matrix table acquisition failures tends to increase. If the frequency of failures increases, the authentication system will increase the number of retries by the user, the matrix table acquisition failure frequency will increase in a chain, and at the same time, there is a risk of receiving a powerful DoS attack. There was a problem.

  The present invention has been made in view of the above, and an object of the present invention is to obtain an authentication system capable of reducing the frequency of failure when acquiring a software token.

  In order to solve the above-described problems and achieve the object, the present invention performs an authentication process using an authentication password composed of a first password that is a fixed password and a second password that is a variable password. An authentication system, a terminal that transmits a predetermined authentication request and a token acquisition request, a rule for obtaining the second password for each user, and an authentication server that performs authentication processing according to the received authentication request And a token acquisition server that returns a token in response to the received token acquisition request, and a detection device that relays communication between the terminal and the token acquisition server, the detection device including the token acquisition server Based on the congestion status of the token acquisition server received at a predetermined period from the token acquisition request received from the terminal. State detection means for determining whether to transfer to the token acquisition server, and the terminal determines the second password based on the token received from the token acquisition server via the detection device and the rule. An authentication password is generated from the first password and the second password, and an authentication request including the authentication password is transmitted to the authentication server as the predetermined authentication request.

  According to the present invention, there is an effect that the failure frequency when acquiring a software token can be reduced.

FIG. 1 is a diagram illustrating a configuration example of an authentication system. FIG. 2 is a diagram illustrating a configuration example of the state detection unit. FIG. 3 is a diagram illustrating a configuration example of the management table. FIG. 4 is a flowchart showing the detection process. FIG. 5 is a flowchart showing packet processing. FIG. 6 is a flowchart showing the output process. FIG. 7 is a diagram illustrating a screen (during congestion) displayed on the token display unit. FIG. 8 is a diagram illustrating a screen (just after the congestion is cleared) displayed on the token display unit. FIG. 9 is a diagram illustrating a screen (when not crowded) displayed on the token display unit. FIG. 10 is a sequence diagram showing processing (during congestion) of the token acquisition server. FIG. 11 is a sequence diagram showing processing of the token acquisition server (immediately after the congestion is eliminated and when it is not crowded). FIG. 12 is a flowchart showing the detection process. FIG. 13 is a flowchart showing the authentication process. FIG. 14 is a flowchart showing the authentication process. FIG. 15 is a flowchart showing the detection process. FIG. 16 is a flowchart showing the detection process. FIG. 17 is a flowchart showing packet processing. FIG. 18 is a flowchart showing the output process. FIG. 19 is a diagram illustrating a screen (when there is a possibility of receiving a DoS attack) displayed on the token display unit. FIG. 20 is a diagram illustrating a screen (when the DoS attack converges) displayed on the token display unit.

  Embodiments of an authentication system according to the present invention will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

Embodiment 1 FIG.
FIG. 1 is a diagram illustrating a configuration example of an authentication system according to the present embodiment. The authentication system includes a terminal 1 used by a user to perform authentication, an access server 3, an authentication server 4, a token acquisition server 6, and a detection device 8, which are networks 2, 5, 7, 9 is connected. In this authentication system, as an example, a password required for authentication is generated by combining a fixed password for each user and a time-variable password obtained from a token. The fixed unit is not limited to the user unit.

  First, the authentication operation of each component, which is a prerequisite for the authentication system of the present embodiment, will be described. The terminal 1 requests a token from the token acquisition server 6, and displays a token display unit 11 that displays the acquired token, and an account input unit 12 that inputs a user ID, a password, and the like and makes an authentication request to the authentication server 4. Prepare. The access server 3 is a general server that is accessed when a terminal connects to the system.

  The authentication server 4 authenticates the one-time password input to the account input unit 12 using the user ID input to the account input unit 12 of the terminal 1 and the token that the user refers to and acquires from the token acquisition server 6. Device. In the authentication server 4, when the password receiving unit 41 receives the user ID and the one-time password via the network 2 and the access server 3, the token pattern obtained from the token generation unit 62 of the token acquisition server 6 via the network 5, The collation unit 43 generates an authentication pattern using a token recognition rule registered in advance in the token recognition unit 42 by the user, and the authentication unit 44 determines whether the pattern is normal.

  The token acquisition server 6 is a device for managing token values to be displayed on the terminal 1. When the user acquires a token, the token acquisition server 6 acquires the token value via the detection device 8 and the network 9. The token acquisition server 6 includes a token transmission / reception unit 61 that transmits / receives the generated talk, a token generation unit 62 that generates a token in response to a request (token acquisition request) from the terminal 1, and the generated token and the correspondence for each user. When receiving a token acquisition request from the terminal 1 or when transmitting a token in response to a request from the authentication server 4, the user ID receiving unit 63 that receives the user ID and the performance of the CPU load of the own server And a performance collection unit 64 that collects.

  The detection device 8 is installed in a segment that can communicate with the token acquisition server 6, and can communicate with the authentication server 4 via the network 7. The detection device 8 includes an interface unit 81, a state detection unit 82, a state output unit 83, a management table 84, and a situation diagnosis unit 85.

  Each time the interface unit 81 receives a packet from the network 9, the interface unit 81 activates a packet filter and collects a traffic list that flows between the terminal 1 and the token acquisition server 6. Based on the collected traffic list, a session connecting the terminal 1 and the token acquisition server 6, an IP address of the terminal 1, an amount of traffic related to the IP address of the terminal 1, and an entry related to the number of accesses are generated, and the management table 84 is updated.

  FIG. 2 is a diagram illustrating a configuration example of the state detection unit 82. The state detection unit 82 receives a request from the terminal 1 to the token acquisition server 6, and outputs a response corresponding to the congestion state of the token acquisition server 6 to the state output unit 83, and the token acquisition server 6, a detection processing unit 822 that determines a congestion state, a token acquisition unit 823 that receives a token from the token acquisition server 6, a congestion state storage table 824 that manages the congestion state of the token acquisition server 6, and an abnormal traffic state And an abnormality detection table 825 to be managed.

  When the status output unit 83 receives information on the congestion status of the token acquisition server 6 notified from the status detection unit 82, the status output unit 83 creates a screen to be displayed on the terminal 1, and transmits the terminal via the interface unit 81 and the network 9. Send a message to 1. The packet transmission from the terminal 1 to the state detection unit 82 and the packet transmission from the state output unit 83 to the terminal 1 can be realized by TCP / IP communication including HTTP.

  FIG. 3 is a diagram illustrating a configuration example of the management table 84. The management table 84 includes a table 841 and a table 842. The table 841 shows the session established in the token acquisition server 6, the IP address and traffic volume of the other party (terminal) communicating with the token acquisition server 6, and the number of accesses from the other party. The interface unit 81 collects entries and reflects them in the table 841.

  The table 842 shows the usage rate of the CPU load and the usage rate of the memory. The detection processing unit 822 collects the CPU load and the memory usage rate from the performance collection unit 64 of the token acquisition server 6 at predetermined intervals and reflects them in the table 842. Regarding the acquisition of the CPU load and the memory usage rate, the detection processing unit 822 of the state detection unit 82 periodically performs SNMP communication with the performance collection unit 64 of the token acquisition server 6, and the SNMP response from the performance collection unit 64 It is realized by acquiring.

  Based on the above configuration and operation, in the present embodiment, the detection device 8 determines the congestion status of the token acquisition server 6 based on the CPU load, and determines the content to be notified to the user based on the congestion status. Will be described.

  FIG. 4 is a flowchart showing the detection process of the detection processing unit 822. First, the detection processing unit 822 collects the CPU load P1 of the token acquisition server 6 from the performance collection unit 64 at a constant cycle (step S1). When the CPU load P1 is larger than the threshold value F1 (step S2: Yes), the token acquisition server 6 determines that it is congested, and updates the congestion state value in the congestion state storage table 824 to “present” (step S3). When the CPU load P1 is less than or equal to the threshold value F1 (step S2: No), it is determined that the token acquisition server 6 is not congested, and the congestion state value in the congestion state storage table 824 is updated to “none” (step S4). When the congestion state changes from “present” to “not present”, or from “none” to “present”, the congestion state change value is changed to “present”.

  Next, packet processing when the packet processing unit 821 receives a token acquisition request from the terminal 1 to the token acquisition server 6 will be described. FIG. 5 is a flowchart showing packet processing of the packet processing unit 821. When detecting the token acquisition request, the packet processing unit 821 collects the transmission IP addresses written in the token acquisition request (step S11). Then, the congestion state value is read from the congestion state storage table 824, and the congestion state value of the token acquisition server 6 is grasped (step S12). When the congestion state value in the congestion state storage table 824 is “present” (step S12: Yes), the congestion state (congested) and the IP address in the congestion state storage table 824 are notified to the state output unit 83 (step S13). In this case, the token acquisition request is not transferred to the token acquisition server 6. On the other hand, when the congestion state value is “none”, that is, in the congestion alleviation state (step S12: No), the token acquisition request is transferred to the token acquisition server 6 and a token is acquired from the token acquisition server 6 as a response (step S14). ). When the change value of the congestion state value is “present” (step S15: Yes), the congestion state (congestion state relaxation), the IP address, and the token are notified to the state output unit 83 (step S16). When the congestion state value change value is “none” (step S15: No), the IP address and token are notified to the state output unit 83 (step S17). Note that when notifying the state output unit 83, the state detection unit 82 stores the correspondence relationship between the token, the IP address of the terminal that acquired the token, and the user ID.

  When the congestion state value in the congestion state storage table 824 is “present” (step S12: Yes), the packet processing unit 821 notifies the state output unit 83 of the congestion state (congested) and the IP address in the congestion state storage table 824. In this case, the process of step S12 is performed at a predetermined cycle. Thereby, when a congestion state eases, the process following step S12: No can be performed.

  When the state output unit 83 receives a notification from the packet processing unit 821 of the state detection unit 82, the state output unit 83 performs output processing on the terminal 1. FIG. 6 is a flowchart showing the output process of the status output unit 83. The status output unit 83 checks the contents (steps S13, S16, S17) determined by the packet processing unit 821 (step S21).

  When the packet processing unit 821 performs the process of step S13 (step S21: step S13), information for outputting the screen 111 shown in FIG. 7 is created (step S22). FIG. 7 is a diagram illustrating a screen 111 (during congestion) displayed on the token display unit. Specifically, this indicates that the token acquisition server 6 is congested for the user, and this refrains from retrying.

  When the packet processing unit 821 performs the process of step S16 (step S21: step S16), information for outputting the screen 112 shown in FIG. 8 is created (step S23). FIG. 8 is a diagram showing a screen 112 (immediately after the congestion is cleared) displayed on the token display unit. Specifically, the token acquired from the token acquisition server 6 and the fact that the token acquisition server 6 can be normally used immediately after the token acquisition server 6 is released from the congested state are shown to the user.

  Further, when the packet processing unit 821 performs the process of step S17 (step S21: step S17), information for outputting the screen 113 shown in FIG. 9 is created (step S24). FIG. 9 is a diagram showing a screen 113 (when not crowded) displayed on the token display unit. Specifically, the token acquired from the token acquisition server 6 is shown to the user, thereby notifying that the token acquisition server 6 is not congested.

  After creating the output screen information, the status output unit 83 transmits a response to the terminal 1 addressed to the notified IP address (step S25). When receiving a response from the status output unit 83, the terminal 1 displays one of the screens 111, 112, and 113 on the token display unit 11.

  Processing according to each of the above configurations will be described with reference to a sequence diagram. FIG. 10 is a sequence diagram showing processing when the token acquisition server 6 is congested. When the terminal 1 transmits a token acquisition request (step S31), the state detection unit 82 that has received the request determines that the token acquisition server 6 is in a congested state based on the processing of the flowcharts shown in FIGS. The state output unit 83 is notified of the congestion state value indicating the fact (step S32). The state output unit 83 creates a screen 111 indicating that the token acquisition server 6 is in a congested state, and transmits it to the terminal 1 (step S33). The terminal 1 displays a screen 111 on the token display unit 11.

  FIG. 11 is a sequence diagram showing processing when the token acquisition server 6 is immediately after congestion is eliminated or when it is not crowded. When the terminal 1 transmits a token acquisition request (step S41), the state detection unit 82 that has received the request determines that the token acquisition server 6 is not congested based on the processing of the flowcharts shown in FIGS. An acquisition request is transmitted to the token acquisition server 6 (step S42). As a response to the token acquisition request, the token acquisition server 6 transmits a token to the state detection unit 82 (step S43). Then, the state detection unit 82 outputs the acquired token and the congestion state value of the token acquisition server 6 to the state output unit 83 (step S44). The state output unit 83 creates a screen (112 or 113) corresponding to the congestion state value of the token acquisition server 6 and transmits it to the terminal 1 together with the token (step S45). The terminal 1 displays a screen 112 on the token display unit 11 when the congestion is reduced, and a screen 113 when the congestion is not.

  The user who is using the terminal 1 can recognize the congestion status of the token acquisition server 6 by obtaining these displays. Therefore, since the user can refrain from retrying when the token acquisition server 6 is congested, the number of retry requests during congestion can be reduced, and excess traffic associated with the retry can be reduced. Moreover, the effect which prevents the state where another user cannot use a token simultaneously can be acquired.

  As described above, in the present embodiment, when the user requests token acquisition, the detection device 8 confirms the congestion state based on the CPU load of the token acquisition server 6 and determines that it is congested. In such a case, the token acquisition request is not transferred to the token acquisition server 6 and the terminal 1 (user) is informed that the retry is not performed. The token acquisition request is transferred to the acquisition server 6 to perform token acquisition processing, and the acquired token is transferred to the terminal 1. As a result, in a congested state, the number of retry requests from the terminal 1 is reduced, so that excess traffic is reduced, and the frequency of failures when other users acquire software tokens in the system can be reduced. .

Embodiment 2. FIG.
In the present embodiment, the detection device 8 determines the congestion status of the token acquisition server 6 using the number of sessions established in the token acquisition server 6. A different part from Embodiment 1 is demonstrated.

  When determining the congestion status based on the number of sessions, the detection processing unit 822 of the detection device 8 can be realized by performing the detection processing shown in FIG. FIG. 12 is a flowchart showing the detection process of the detection processing unit 822. First, the detection processing unit 822 collects the total number of sessions P2 established between the terminal 1 and the token acquisition server 6 using the table 841 shown in FIG. 3 (step S51). When the collected number of sessions P2 is larger than the predetermined threshold value F2 (step S52: Yes), the token acquisition server 6 determines that it is congested, and changes the congestion state value in the congestion state storage table 824 to “present” ( Step S53). When the total number of sessions P2 is less than or equal to the threshold value F2 (step S52: No), it is determined that the token acquisition server 6 is not congested, and the congestion state value in the congestion state storage table 824 is changed to “none” (step S54). . When the congestion state changes from “present” to “not present”, or from “none” to “present”, the congestion state change value is changed to “present”.

  Thereafter, the processing of the packet processing unit 821, the status output unit 83, and the terminal 1 is the same as that of the first embodiment. When the token acquisition server 6 is congested, the terminal 1 displays the screen 111 (see FIG. 7) through the processing shown in FIG. On the other hand, when the token acquisition server 6 is not congested, the terminal 1 displays the screen 112 (see FIG. 8) or the screen 113 (see FIG. 9) through the processing shown in FIG.

  As described above, in the present embodiment, when the user requests token acquisition, the detection device 8 confirms the congestion state based on the number of sessions established in the token acquisition server 6. . Thereby, the effect similar to Embodiment 1 can be acquired.

Embodiment 3 FIG.
In the present embodiment, the authentication server 4 performs notification of congestion status to the terminal 1. A different part from Embodiment 1, 2 is demonstrated.

  In the authentication system, the status diagnosis unit 85 of the detection device 8 can read the contents of the management table 84 and communicates with the authentication server 4 regarding the state of the token acquisition server 6. The situation diagnosis unit 85 is connected to the authentication server 4 via the network 7.

  When the authentication server 4 receives the user ID and the one-time password from the terminal 1 at the password receiving unit 41, the verification unit 43 passes the token recognition rule registered in the token recognition unit 42 by the user in advance and the network 5. The one-time password is verified using the token obtained from the token acquisition server 6 and the authentication unit 44 performs authentication. The authentication unit 44 determines whether to perform authentication processing based on the congestion state of the token acquisition server 6.

  Next, the authentication process of the authentication unit 44 will be described. FIG. 13 is a flowchart showing the authentication process of the authentication unit 44. When the authentication unit 44 first inputs an account from the verification unit 43 (step S61), the authentication unit 44 inquires of the status diagnosis unit 85 about the congestion state of the token acquisition server 6 (step S62). When the situation diagnosis unit 85 receives an inquiry from the authentication unit 44, the situation diagnosis unit 85 reads the congestion state value in the congestion state storage table 824 and returns the result to the authentication unit 44. The authentication unit 44 confirms the content of the response from the situation diagnosis unit 85, and in the case of a congestion state (the congestion state value is “Yes”) (step S63: Yes), the authentication response packet indicates the reason for indicating an authentication NG response and server congestion. And responds to the terminal 1 via the access server 3 (step S64). On the other hand, when it is not in a congested state (the congested state value is “none”) (step S63: No), a process for determining the validity of the password is performed, and an authentication response is returned according to the validity of the password (step S65).

  When authentication using a software token is applied to a remote access service, a screen for displaying a token may be different from an authentication screen in order to facilitate cooperation between applications. In such a case, when the authentication server 4 performs the above process, the user can quickly recognize the congestion state of the token acquisition server 6 through the authentication screen.

  As described above, in the present embodiment, the authentication server 4 notifies the user of the congestion status of the token acquisition server 6. Thereby, the same effect as Embodiments 1 and 2 can be obtained.

Embodiment 4 FIG.
In the present embodiment, the IP address information of the terminal 1 is taken into account in the authentication process performed by the authentication unit 44 of the authentication server 4. A different part from Embodiment 3 is demonstrated.

  For example, in the terminal 1, in order to prioritize cooperation with an existing authentication system, the token display unit 11 and the account input unit 12 may be provided by different software. In this case, when the token is displayed on the token display unit 11 of a certain terminal and information necessary for authentication is input from the account input unit 12 of a different terminal, the authentication server 4 has a terminal that has acquired the token and a terminal that requests authentication. There is a security problem that authentication processing is performed even if they are different. Therefore, in this embodiment, authentication processing is performed only when the terminal that acquired the token and the terminal that issued the authentication request are the same terminal.

  Processing until the authentication server 4 receives the user ID and the one-time password from the terminal 1 by the password receiving unit 41 and collates by the collating unit 43 is the same as that of the third embodiment. FIG. 14 is a flowchart showing the authentication process of the authentication unit 44. First, the authentication unit 44 inputs an account from the verification unit 43 (step S71), and obtains the IP address Y of the terminal 1 that has requested the authentication request (step S72). Next, the authenticating unit 44 transfers the user ID to the situation diagnosing unit 85 of the detecting device 8 and makes an inquiry. When receiving the user ID from the authentication unit 44, the situation diagnosis unit 85 relates to the user ID based on the correspondence relationship between the token stored when the token is transmitted to the terminal, the user ID of the terminal, and the IP address. The IP address X of the terminal 1 that has acquired the token is obtained. The situation diagnosis unit 85 transmits the acquired IP address X to the authentication unit 44 as a response to the inquiry.

  The authentication unit 44 receives the response from the situation diagnosis unit 85 (step S73), and confirms whether the IP address Y and the IP address X are the same (step S74). If they are not the same (step S74: No), the authentication NG response and the reason (error message) indicating unauthorized access are input to the authentication response packet, assuming that the terminal that has acquired the token and the terminal that requested the authentication are different terminals. A response is made to the terminal 1 via the server 3 (step S75). If they are the same (step S74: Yes), it is assumed that the terminal that acquired the token and the terminal that requested the authentication are the same terminal, and the process of determining the validity of the password is performed, and an authentication response is returned according to the validity of the password (step) S76).

  As described above, in this embodiment, authentication processing is performed when the terminal that acquired the token and the terminal that requested authentication are the same. Thereby, in addition to the effect of the third embodiment, the security of the authentication system can be further improved.

Embodiment 5 FIG.
In the present embodiment, the detection device 8 detects an abnormal state based on the traffic amount addressed to the token acquisition server 6. A different part from Embodiment 1 is demonstrated.

  The detection device 8 can detect and specify the traffic amount from the table 841 (see FIG. 3) of the management table 84. FIG. 15 is a flowchart showing the detection processing of the detection processing unit 822. The detection processing unit 822 collects the traffic amount T of each session in the table 841 of the management table 84, and specifies the largest traffic amount T1 and the IP address C of the source terminal (step S81). When the identified traffic amount T1 is larger than the preset threshold value G1 (step S82: Yes), the abnormal state value in the abnormality detection table 825 is changed to “present” (step S83). Further, the acquired IP address C of the transmission source terminal is stored in the abnormality detection table 825 (step S84). On the other hand, when the specified traffic amount T1 is equal to or less than the preset threshold value G1 (step S82: No), the process ends.

  When the detection processing unit 822 detects an abnormality (step S82: Yes), the process is performed based on the flowchart of FIG. First, the traffic amount Q of the terminal having the IP address C detected in step S81 in FIG. 15 is calculated (step S91). When the calculated traffic amount Q is smaller than the threshold value G2 (step S92: Yes), the following processing is performed.

  Since there is a possibility that the traffic of the DoS attack is once in a lull state, the threshold value G2 is set to a value smaller than the threshold value G1, and when the traffic amount becomes smaller than the threshold value G2 (step S92: Yes), the frequency H is incremented. (Step S93). However, if a traffic amount exceeding the threshold value G1 is detected again, the number of times H is reset to zero. When the number of times H reaches the predetermined number of times J (step S94: Yes), that is, when the traffic amount is smaller than the threshold value G2 for a predetermined period, the abnormal state change value of the abnormality detection table 825 is set to “present”. The abnormal state value in the abnormality detection table 825 is updated to “None” (step S95). If the calculated traffic amount Q is greater than or equal to the threshold value G2 (step S92: No), and if the number of times H does not reach the predetermined number of times J (step S94: No), the process is terminated. The detection processing unit 822 repeatedly performs the process shown in FIG. 16 at a predetermined cycle.

  Next, packet processing of the packet processing unit 821 will be described. FIG. 17 is a flowchart showing packet processing of the packet processing unit 821. First, when receiving a token acquisition request from the terminal 1 (step S101), the packet processing unit 821 confirms an abnormal state value in the abnormality detection table 825 (step S102). When the abnormal state value is “present” (step S102: Yes), it is further confirmed whether or not the IP address of the token acquisition request matches the IP address C detected in the process of step S81 of FIG. 15 (step S103). . If they match (step S103: Yes), the traffic from the terminal that sent this token acquisition request is blocked (step S104). When they do not match (step S103: No), the abnormal state value and the IP address are notified to the state output unit 83 (step S105). When the abnormal state value is “present”, the token acquisition request is not transferred to the token acquisition server 6.

  On the other hand, when the abnormal state value is “none” (step S102: No), the packet processing unit 821 further confirms the abnormal state change value in the abnormality detection table 825 (step S106), and the abnormal state change value is “present”. ”(Step S106: Yes), since there is a possibility that the decryption pattern has been analyzed by the DoS attack, the abnormal state value and the IP address are notified to the state output unit 83 (step S107). In this case, the token acquisition request is not transferred to the token acquisition server 6. If no abnormal traffic is detected after a predetermined time has elapsed, the abnormal state change value is updated to “none”. When the abnormal state change value is “None” (step S106: No), the token acquisition request is transferred to the token acquisition server 6, and a token is acquired from the token acquisition server 6 as a response (step S108). Is notified to the state output unit 83 (step S109).

  As in the case of the first embodiment, when the abnormal state value is “present” (step S102: Yes), the process of step S102 is performed at a predetermined cycle. Thereby, the process following step S102: No can be performed when the abnormal state is resolved.

  When the state output unit 83 receives a notification from the packet processing unit 821 of the state detection unit 82, the state output unit 83 performs output processing on the terminal 1. FIG. 18 is a flowchart showing the output process of the state output unit 83. The status output unit 83 confirms the contents (steps S105, S107, and S109) determined by the packet processing unit 821 (step S111).

  When an abnormal state is detected (step S111: step S105), information for outputting the screen 114 shown in FIG. 19 is created (step S112). FIG. 19 is a diagram showing a screen 114 (when there is a possibility of receiving a DoS attack) displayed on the token display unit. This indicates that the user may have been subjected to a DoS attack. In this case, the information on the screen 114 is transmitted to the terminal 1 to prompt the change of the pattern registered by the terminal 1, and the pattern initialization is performed for the token recognition unit 42 of the authentication server 4 via the status diagnosis unit 85. Notify the message. Upon receiving this notification, the authentication server 4 initializes the registered pattern registration rule. After initialization, it waits for a new pattern from the terminal 1 to be registered.

  If it is not long after recovery from the abnormal state (step S111: step S107), information for outputting the screen 115 shown in FIG. 20 is created (step S113). FIG. 20 is a diagram illustrating a screen 115 (when the DoS attack converges) displayed on the token display unit. This indicates to the user that the DoS attack has converged. Also in this case, the information on the screen 115 is transmitted to the terminal 1 to prompt the change of the pattern registered by the terminal 1, and the pattern initialization is performed to the token recognition unit 42 of the authentication server 4 via the status diagnosis unit 85. Notify the message to be performed.

  Also, when no abnormal traffic is detected (step S111: step S109), information for outputting the screen 113 shown in FIG. 9 is created (step S114), as in the first embodiment.

  After creating the output screen information, the status output unit 83 transmits a response to the terminal 1 addressed to the notified IP address (step S115). When the terminal 1 receives the response from the state output unit 83, the terminal 1 displays one of the screens 114, 115, and 113 on the token display unit 11.

  In this way, particularly when the token acquisition server 6 is connected to the Internet, it is possible to prevent a DoS attack and to notify the user of the possibility of receiving the DoS attack.

  As described above, in the present embodiment, when the state detection unit 82 detects an abnormal state based on the traffic amount addressed to the token acquisition server 6 and the token acquisition server 6 is connected to the Internet, the DoS The token can be secured by preventing attacks. Thereby, in addition to the effect of the first embodiment, the security of the authentication system can be further improved.

  Note that the processing of each embodiment can be combined with each other. For example, in the case of the fifth embodiment, the authentication server 4 can perform the authentication process of the third and fourth embodiments.

  As described above, the authentication system according to the present invention is useful for user authentication, and is particularly suitable for authentication using a password combining software tokens.

DESCRIPTION OF SYMBOLS 1 Terminal 2, 5, 7, 9 Network 3 Access server 4 Authentication server 6 Token acquisition server 8 Detection apparatus 11 Token display part 12 Account input part 41 Password receiving part 42 Token recognition part 43 Verification part 44 Authentication part 61 Token transmission / reception part 62 Token generation unit 63 User ID reception unit 64 Performance collection unit 81 Interface unit 82 Status detection unit 83 Status output unit 84 Management table 85 Status diagnosis unit 821 Packet processing unit 822 Detection processing unit 823 Token acquisition unit 824 Congestion state storage table 825 Abnormality detection table

Claims (31)

An authentication system that performs an authentication process using an authentication password composed of a first password that is a fixed password and a second password that is a variable password,
A terminal that transmits a predetermined authentication request and token acquisition request;
An authentication server for storing a rule for determining the second password for each user and performing an authentication process in response to the received authentication request;
A token acquisition server that returns a token in response to the received token acquisition request;
A detection device that relays communication between the terminal and the token acquisition server;
With
The detection device includes:
State detection means for determining whether to transfer the token acquisition request received from the terminal to the token acquisition server based on the congestion state of the token acquisition server received from the token acquisition server at a predetermined cycle;
With
The terminal
Determining the second password based on the token received from the token acquisition server via the detection device and the rule, and generating an authentication password from the first password and the second password, As an authentication request, an authentication request including the authentication password is transmitted to the authentication server.
An authentication system characterized by that. The detection device further includes:
A management table for storing the congestion status of the token acquisition server;
With
In the state detection means,
When the token acquisition request is received from the terminal, the congestion state of the token acquisition server stored in the management table is confirmed, and if the value indicating the congestion state is larger than a predetermined threshold, the token acquisition server When it is determined that the acquisition request is not transferred and information indicating that the request is congested is transmitted to the terminal, on the other hand, when the value indicating the congestion state is equal to or less than a predetermined threshold, the token acquisition server is processed. Determining that the token acquisition request is to be transferred, and performing processing for transferring the token acquisition request to the token acquisition server and processing for transferring the token received from the token acquisition server as a response to the terminal,
The authentication system according to claim 1, wherein: When receiving information indicating that the terminal is congested from the detection device, the terminal displays the content on a screen after transmitting a token acquisition request.
The authentication system according to claim 2, wherein: In the management table, further storing state change information indicating whether the latest congestion state has changed compared to the previously received congestion state,
The state detection means further checks the state change information if the value indicating the congestion state of the token acquisition server is equal to or less than the predetermined threshold, and if the result of the confirmation is that there is a change, the congestion state is indicated together with the token. Perform processing to send information indicating that it has just been relaxed,
The authentication system according to claim 2 or 3, wherein The detection device further includes:
A status diagnosing means for searching the management table in response to a request from the authentication server and returning the acquired information to the authentication server;
With
The authentication server is
When an authentication request is received from the terminal, a request for acquiring the congestion status of the token acquisition server is transmitted to the status diagnosis unit, the congestion status is received as a response, and the congestion status of the token acquisition server is represented. When the value is larger than the predetermined threshold, the information indicating that the authentication is not performed is transmitted to the terminal together with the information indicating that the authentication is not performed.
The authentication system according to claim 2, 3, or 4. When the terminal receives the information indicating that the authentication is not performed and the information indicating that the terminal is congested, the content is displayed on a screen after the authentication request is transmitted.
The authentication system according to claim 5. When the management table further stores the IP address of the terminal that received the token from the token acquisition server,
The authentication server is
When an authentication request is received from the terminal, the status diagnosis unit is requested to request the IP address of the terminal receiving the same token as the token received by the terminal, and the IP address received as the response It compares the IP address of the terminal that sent the authentication request, and if the IP address is different as a result of the comparison, sends an error message to the terminal that sent the authentication request.
The authentication system according to claim 5 or 6, wherein When the traffic amount for each session established by the token acquisition server and the IP address of the transmission source terminal of the traffic and the IP address of the terminal in an abnormal state are further stored in the management table,
The state detection means includes
When the maximum traffic volume is larger than the first threshold value, the traffic transmission source terminal is stored as being in an abnormal state, and then the traffic volume from the terminal is set to the second threshold value (first threshold value over a predetermined period). In the case of performing an operation for canceling the abnormal state when the threshold value> the second threshold value) becomes smaller,
When the token acquisition request is received from the predetermined terminal and the abnormal terminal is recorded and the predetermined terminal and the abnormal terminal are the same, the traffic of the predetermined terminal is blocked. Process for
On the other hand, when the token acquisition request is received from the predetermined terminal and the abnormal terminal is recorded and the predetermined terminal is different from the abnormal terminal, information indicating the abnormal state is displayed. Perform a process to reply to the specified terminal,
Furthermore, when a token acquisition request is received from a predetermined terminal and there is a record indicating that it has been in an abnormal state in the past, a process for returning information to that effect to the predetermined terminal is performed,
When the state diagnosis unit performs processing for transmitting information indicating an abnormal state or information indicating an abnormal state in the past by the state detection unit, Send information to initialize the rules,
The authentication server that has received the information for initializing the rule initializes the rule, and transmits information to that effect to the terminal of the token acquisition request transmission source.
The authentication system according to claim 5, 6, or 7. The state detection means determines the congestion state based on a CPU load of the token acquisition server;
The authentication system according to any one of claims 1 to 8, wherein: The state detection means determines the congestion state based on the number of sessions established by the token acquisition server.
The authentication system according to any one of claims 1 to 8, wherein: Authentication using an authentication password composed of a terminal that transmits a predetermined authentication request and token acquisition request, and a first password that is a fixed password and a second password that is a variable password according to the received authentication request An authentication server that performs processing and stores a rule for determining the second password for each user, a token acquisition server that returns a token in response to the received token acquisition request, and the terminal and the token acquisition server A detecting device that relays communication between the detecting device in an authentication system comprising:
State detection means for determining whether to transfer the token acquisition request received from the terminal to the token acquisition server based on the congestion state of the token acquisition server received from the token acquisition server at a predetermined cycle;
A detection apparatus comprising: further,
A management table for storing the congestion status of the token acquisition server;
With
In the state detection means,
When the token acquisition request is received from the terminal, the congestion state of the token acquisition server stored in the management table is confirmed, and if the value indicating the congestion state is larger than a predetermined threshold, the token acquisition server When it is determined that the acquisition request is not transferred and information indicating that the request is congested is transmitted to the terminal, on the other hand, when the value indicating the congestion state is equal to or less than a predetermined threshold, the token acquisition server is processed. Determining that the token acquisition request is to be transferred, and performing processing for transferring the token acquisition request to the token acquisition server and processing for transferring the token received from the token acquisition server as a response to the terminal,
The detection device according to claim 11. In the management table, further storing state change information indicating whether the latest congestion state has changed compared to the previously received congestion state,
The state detection means further checks the state change information if the value indicating the congestion state of the token acquisition server is equal to or less than the predetermined threshold, and if the result of the confirmation is that there is a change, the congestion state is indicated together with the token. Perform processing to send information indicating that it has just been relaxed,
The detection device according to claim 12. further,
A status diagnosing means for searching the management table in response to a request from the authentication server and returning the acquired information to the authentication server;
The detection device according to claim 12, further comprising: When the management table further stores the IP address of the terminal that received the token from the token acquisition server,
In response to a request from the authentication server, the situation diagnosis unit returns an IP address of a terminal that has received the same token as the token received by the terminal that has transmitted the authentication request to the authentication server.
The detection apparatus according to claim 14. When the traffic amount for each session established by the token acquisition server and the IP address of the transmission source terminal of the traffic and the IP address of the terminal in an abnormal state are further stored in the management table,
The state detection means includes
When the maximum traffic volume is larger than the first threshold value, the traffic transmission source terminal is stored as being in an abnormal state, and then the traffic volume from the terminal is set to the second threshold value (first threshold value over a predetermined period). In the case of performing an operation for canceling the abnormal state when the threshold value> the second threshold value) becomes smaller,
When the token acquisition request is received from the predetermined terminal and the abnormal terminal is recorded and the predetermined terminal and the abnormal terminal are the same, the traffic of the predetermined terminal is blocked. Process for
On the other hand, when the token acquisition request is received from the predetermined terminal and the abnormal terminal is recorded and the predetermined terminal is different from the abnormal terminal, information indicating the abnormal state is displayed. Perform a process to reply to the specified terminal,
Furthermore, when a token acquisition request is received from a predetermined terminal and there is a record indicating that it has been in an abnormal state in the past, a process for returning information to that effect to the predetermined terminal is performed,
When the state diagnosis unit performs processing for transmitting information indicating an abnormal state or information indicating an abnormal state in the past by the state detection unit, Sending information to initialize the rules;
The detection apparatus according to claim 14 or 15, wherein The state detection means determines the congestion state based on a CPU load of the token acquisition server;
The detection device according to any one of claims 11 to 16, wherein The state detection means determines the congestion state based on the number of sessions established by the token acquisition server.
The detection device according to any one of claims 11 to 16, wherein Authentication using an authentication password composed of a terminal that transmits a predetermined authentication request and token acquisition request, and a first password that is a fixed password and a second password that is a variable password according to the received authentication request An authentication server that performs processing and stores a rule for determining the second password for each user, a token acquisition server that returns a token in response to the received token acquisition request, and the terminal and the token acquisition server A detection apparatus that relays communication between the terminals in the authentication system,
Based on the congestion state of the token acquisition server received from the token acquisition server at a predetermined cycle, the detection apparatus determines to transfer the token acquisition request received from the terminal to the token acquisition server, and transfers the token acquisition request transferred. When the token received from the token acquisition server as a response to is transferred to the terminal,
Determining the second password based on the token received from the token acquisition server via the detection device and the rule, and generating an authentication password from the first password and the second password, As an authentication request, an authentication request including the authentication password is transmitted to the authentication server.
A terminal characterized by that. When the detection device receives a token acquisition request, the token acquisition server checks the congestion state of the token acquisition server stored in the management table, and when the value indicating the congestion state is larger than a predetermined threshold, the token acquisition server When it is determined that the token acquisition request will not be transferred to
Displaying information on the congestion received from the detection device on the screen after sending the token acquisition request,
The terminal according to claim 19. When the authentication server receives an authentication request, the authentication server confirms the congestion state of the token acquisition server stored in the management table of the detection device, and when the value indicating the congestion state is greater than the predetermined threshold If you send information indicating that it is crowded along with information indicating that you will not be authenticated,
Displaying the information received from the authentication server indicating that authentication is not performed and the information indicating that the authentication server is congested on the screen after transmitting the authentication request;
The terminal according to claim 20, wherein: Authentication using an authentication password composed of a terminal that transmits a predetermined authentication request and token acquisition request, and a first password that is a fixed password and a second password that is a variable password according to the received authentication request An authentication server that performs processing and stores a rule for determining the second password for each user, a token acquisition server that returns a token in response to the received token acquisition request, and the terminal and the token acquisition server An authentication method in an authentication system comprising a detection device that relays communication between,
A determination step for determining whether the detection device forwards the token acquisition request received from the terminal to the token acquisition server based on a congestion state of the token acquisition server received from the token acquisition server at a predetermined period; ,
The terminal determines the second password based on the token received from the token acquisition server via the detection device and the rule, and generates an authentication password from the first password and the second password An authentication password generation step;
An authentication request transmission step in which the terminal transmits an authentication request including the authentication password to the authentication server as the predetermined authentication request;
An authentication method comprising: When the detection device comprises a management table for storing the congestion status of the token acquisition server,
In the determination step, when the token acquisition request is received from the terminal, the congestion state of the token acquisition server stored in the management table is confirmed, and when the value indicating the congestion state is larger than a predetermined threshold, When it is determined that the token acquisition request is not transferred to the token acquisition server and information indicating that the request is congested is transmitted to the terminal. On the other hand, when the value indicating the congestion state is equal to or less than a predetermined threshold, the token acquisition server Determining that the token acquisition request is to be transferred, and transferring the token received from the token acquisition server as a response to the process for transferring the token acquisition request to the token acquisition server;
The authentication method according to claim 22. further,
When the terminal receives information indicating that the terminal is crowded, a token acquisition request screen display step for displaying the content on a screen after transmitting the token acquisition request;
The authentication method according to claim 23, further comprising: In the management table, further storing state change information indicating whether the latest congestion state has changed compared to the previously received congestion state,
In the determination step, if the value indicating the congestion state of the token acquisition server is equal to or less than the predetermined threshold, the state change information is further confirmed. If the result of the confirmation is that there is a change, the congestion state is reduced together with the token. Send information indicating that it is immediately after
The authentication method according to claim 23 or 24, wherein: further,
When the authentication server receives an authentication request from the terminal, the token acquisition server transmits a request for acquiring the congestion state of the token acquisition server to the verification device, and receives the congestion state as a response thereto. A congestion state authentication step of transmitting information indicating that it is congested together with information indicating that no authentication is performed to the terminal when the value indicating the congestion state of
The authentication method according to claim 23, 24, or 25, comprising: further,
An authentication request screen display step for displaying the content on the screen after transmitting the authentication request when the terminal receives the information indicating that the terminal is not authenticated and the information indicating that the terminal is congested;
The authentication method according to claim 26, further comprising: When the IP address of the terminal that acquired the token from the token acquisition server is further stored in the management table,
further,
When the authentication server receives an authentication request from the terminal, the verification server requests the IP address of the terminal receiving the same token as the token received by the terminal, and receives it as a response An IP address authentication step of transmitting an error message to the terminal that has transmitted the authentication request if the IP address is different as a result of the comparison, and the IP address of the terminal that transmitted the authentication request is compared
The authentication method according to claim 26 or 27, further comprising: This is a case where the management table further stores the traffic volume for each session established by the token acquisition server, the IP address of the transmission source terminal of the traffic, and the IP address of the terminal in an abnormal state. And when the maximum traffic volume is larger than the first threshold, the verification device stores the traffic source terminal as being in an abnormal state, and then the traffic volume from the terminal over a predetermined period. In the case of performing an operation of canceling the abnormal state when the value becomes smaller than the second threshold (first threshold> second threshold),
further,
When the verification device receives a token acquisition request from a predetermined terminal and the abnormal terminal is recorded, and the predetermined terminal and the abnormal terminal are the same, the predetermined terminal A first abnormal state determination step for blocking the traffic of
When the verification device receives a token acquisition request from a predetermined terminal and the abnormal terminal is recorded, and the predetermined terminal is different from the abnormal terminal, the verification apparatus is in an abnormal state. A second abnormal state determination step of returning the information to the predetermined terminal;
When the verification device receives a token acquisition request from a predetermined terminal and has a record indicating that it has been in an abnormal state in the past, a third information is sent back to the predetermined terminal. An abnormal state determination step;
In order to initialize the rule to the authentication server when the verification device performs processing for transmitting information indicating an abnormal state or information indicating an abnormal state in the past An initialization instruction step for transmitting the information of
An authentication server that receives the information for initializing the rule, initializes the rule, and transmits an information to that effect to the token acquisition request transmission source terminal; and
The authentication method according to claim 26, 27 or 28, wherein: In the determination step, the congestion state of the token acquisition server is determined based on the CPU load of the token acquisition server.
30. The authentication method according to any one of claims 22 to 29, wherein: In the determination step, the congestion state of the token acquisition server is determined based on the number of sessions established by the token acquisition server.
30. The authentication method according to any one of claims 22 to 29, wherein:

Images