TWI394420B - Ip address secure multi-channel authentication for online transactions - Google Patents

Description

IP address secure multi-channel authentication for online transactions

The present invention relates to an IP address secure multi-channel authentication method, and more particularly to a multi-factor authentication method for users using an application server and an authentication server.

Online transactions, including financial transactions and other classified transactions, have long been used to allow both parties to conduct business activities. In a typical online transaction, a user (such as a bank customer) uses a client browser on the computer to establish a session with an application server (such as a banking server operated by a bank) and achieve the desired Transactions (such as transferring money from one account to another). Because online transactions are often carried out over the Internet, which is a global public network of routers, servers, trunks, etc., security is always a top priority.

The risk of online transaction security includes the possibility that an unauthorized third party may be able to obtain authentication information (such as a user identification and password) and may subsequently be able to conduct fraudulent transactions that are unfavourable to the user. For example, if you log in to a bank from any computer and only need a user ID and password, a third party that obtains the user's user ID and password will be able to log in from anywhere and perform any transaction that the user can perform, for example, including unauthorized access. Transfer money to an account under the control of the three parties.

The theft of the user's identity and password can be by, for example, a Trojan (usually an application residing on the client) that listens for the user ID and password and forwards the user ID and password to the fraud when the user ID and password are typed by the user. Technology) Now. Another technique involves phishing. In the example of a phishing scenario, a user may receive an email with a message requesting the user to log in to a website (eg, XYZ Bank) of a merchant who has previously engaged in a business activity with a user. The email contains a link to be initiated by the user. If the user initiates a link provided by a phishing email, then a website is presented to the user, which has almost the same look and feel as a real website (eg, XYZ Bank). However, the site is actually a fraudster. The information in the fraudster's website that the user enters into the look and feel of the mock simulation website will be recorded and subsequently used to commit fraud to the user. For example, a fraudster can use the entered user ID and password to log in to the user's account and perform an unauthorized money transfer.

One method of preventing fraud such as Trojans or phishing involves the use of second factor authentication, where authentication requires additional information. Due to the user identification/password acting as the first authentication factor, the application server (eg, banking application) also needs additional authentication based on the device being used for access or the hardware owned by the user. For example, a second factor authentication may require a hardware token or an ATM card. Software can also be used as a second factor authentication.

The above mentioned only touches on the online trading risks of some broad categories. There are other risks that currently exist, but they are well known and will not be explained too much here. In addition, technology is constantly evolving to prevent online fraud. Accordingly, fraudsters continue to develop technology to overcome new security measures, including authentication schemes.

Improved authentication techniques are needed in view of the transaction risks that currently exist and/or appear in response to security measures.

Accordingly, the present invention provides a method for multi-factor authentication of a user using an application server and an authentication server to solve the above problem.

According to an aspect of the present invention, there is provided a computer implemented method for multi-factor authentication of a user using an application server and an authentication server, the user interacting with the application server and the authentication server, the user Communicating with at least one of the application server and the authentication server using a user browser program, the method comprising: authenticating the user with a first factor authentication certificate using the application server; from the application Providing, by the server, the first source IP address of the user to the authentication server, where the first source IP address is when the user submits the authentication request to the authentication server Correlation information transmitted by the factor authentication certificate; instructing the user to establish an independent communication channel between the user browser program and the authentication server to perform additional authentication; comparing the first source IP address and utilization a second source IP address of the independent communication channel associated with communication from the user to the authentication server; and if the first source IP address and the first If the two source IP addresses do not match, the authentication of the user fails.

According to another aspect of the present invention, there is provided a computer implemented method for multi-factor authentication of a user using an application server and an authentication server, the user utilizing a user browser program with the application server and the authentication server At least one of the interactions, the method comprising: receiving, from the application server, a first source IP address associated with an authentication request from the user browser program to the application server; from the user The browser program receives the request to perform additional authentication between the user browser program and the authentication server using an independent communication channel, the independent communication channel being used in the application server and the authentication server The communication channel for communication between the devices is independent; comparing the first source IP address and performing the addition between the authentication server and the user browser program The second source IP address associated with the request for authentication; and if the first source IP address does not match the second source IP address, the authentication of the user fails.

The invention will now be described in detail with reference to a few embodiments illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in the However, it will be apparent to those skilled in the art that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to avoid unnecessarily obscuring the invention.

Various embodiments are described below, including methods and techniques. It should be borne in mind that the present invention may also encompass an article of manufacture comprising a computer readable medium storing computer readable instructions for performing embodiments of the inventive techniques. For example, a computer readable medium can comprise a semiconductor, magnetic, magneto-optical, optical, or other form of computer readable medium for storing computer readable code. Further, the invention may also encompass apparatus for practicing embodiments of the invention. Such a device may include circuitry dedicated to and/or programmable for performing tasks related to embodiments of the present invention. Examples of such devices include general purpose computers and/or special purpose computing devices in the context of proper programming, and may include a combination of computer/computing devices and special/programmable circuits suitable for the various tasks associated with embodiments of the present invention.

In the multi-channel authentication scheme, the user not only needs to access the application server (for example, the XYZ bank mentioned above), but also needs to access the authentication server on the independent communication for the purpose of authenticating himself. Simply put, a multi-channel authentication scheme consists of three parties: the user, the application server, and the authentication server.

In general, the user first logs in to the application server (for example, XYZ Bank) and creates His first factor authentication certificate (for example, user ID and password). Once the first factor authentication certificate is met, the application server contacts the authentication server to determine if the user is a subscriber to the multi-channel authentication service. If the user is a subscriber to the multi-channel authentication service, the authentication server (via the application server) provides the user with an HTML command to instruct the user's client browser (eg, using AJAX technology) to establish an independent communication channel with the authentication server. . Communication in this independent communication channel can be made secure by using an encryption technique that will be discussed later. Additional authentication is performed on the secure channel between the user's browser and the authentication server on the separate second channel.

In one embodiment, both the client browser and the authentication server know a common secret. A portion of the shared secret is referred to herein as a "known fact" or KF, which is known to both the authentication server and the client browser. The known fact may be any material, information or fact that is indicated as "known" by the authentication server and the client browser. For example, the known fact may be a special data field (eg, an account number or a phone number) that is indicated by the merchant as a shared secret for additional authentication.

Authentication between the authentication server and the client browser is a two-way encryption authentication. If the client browser can authenticate itself to the authentication server using the shared secret (which is known to both the authentication server and the client browser), and if the authentication server can authenticate itself to the client browser using the shared secret, then Certification is considered successful. In order to communicate the known facts, a startup process (one-time processing for each device) when the user initially registers with the multi-channel authentication system.

Security is enhanced during out-of-band communication channels (eg, email, phone, etc.). For example, an email may be sent to the user to provide an alphanumeric string of known facts to the user to the user to bind the user to his certificate.

While multi-channel authentication technology can provide additional security measures for some form of security risk, the form of attack known as man-in-the-middle (MITM) has presented challenges. A man-in-the-middle attack refers to a fraudster using a device connected to the client and connected to the application server to relay data and/or pretend to act on behalf of the client browser for fraud purposes by relaying requests and responses. In other words, the intermediary device can see all the traffic and perform most or all of the actions that can be performed by the client browser, including, for example, modifying the SSL protocol information.

Therefore, even with the multi-channel authentication scheme, after the client browser successfully implements additional authentication with the authentication server, it is still possible to disclose confidential communication because the intermediary device is embedded in the client browser and the application server (for example , XYZ Bank) in the communication between. In one or more embodiments of the invention, an IP Address Secure Multi-Channel Authentication (IPAS-MCA) technique and apparatus is presented. In general, the AS-MCA technology detects the IP source address used for communication between the client browser and the application server and the communication between the client browser and the authentication server on the secure authentication channel. Whether the source IP address is the same. If the two IP addresses are different, an unauthorized intermediary device is suspected and the authentication will fail.

The features and advantages of the present invention are better understood by reference to the appended claims. FIG. 1 illustrates a typical multi-channel authentication scheme in which a client browser 102 utilizes both the application server 104 and the authentication server 106 for authentication. First, the client browser 102 contacts the application server 104 to request authentication (130). At this stage, as is traditionally used, authentication typically uses a combination of user identification and password. If the user is considered to be a valid user based on the user identification/password, it is determined whether the user of the client browser 102 is a subscriber of the multi-channel authentication system. The subscriber database can be passed by the authentication server 106, for example The identity of the user is checked (which is forwarded (132) by the application server 104 to the authentication server 106) to make a decision.

If it is determined that the user is a subscriber of the multi-channel authentication system, the authentication server 106 sends (134) instructions (eg, in the form of HTML code) to the client browser 102 via the application server 104 for the purpose of performing further authentication to indicate The client browser 102 establishes a secure communication channel with the authentication server 106.

Using the instructions provided by the authentication server 106 (which is sent to the client browser 102 via the application server 104), the client browser 102 then establishes a secure communication channel (136A/136B) to the authentication server 106. The client browser 102 and the authentication server 106 can perform further authentication via the secure communication channel. Authentication is generally two-way, and the client browser authenticates itself to the authentication server and vice versa.

In general, additional authentication may require information that is only known to the user and/or that is specific to the communication device that is registered with the multi-channel authentication system as belonging to the user and authorized to perform the transaction. Thus, even if the user identification and password are stolen, the fraudster cannot complete the authentication because the additional authentication with the authentication server requires additional information specific to the user and/or the authorized user device.

Figure 2 illustrates the presence of a middleman device 110 that has been implemented by a fraudster for the purpose of fraudulent purposes to a user. Typically, the fraudster attempts to trick the user into making a connection to the intermediary device 110 based on an excuse. Once connected based on some seemingly real excuse, the fraudster's intermediary device 110 then provides a connection to the application server 104 on behalf of the user's browser 102, the fraudster's intermediary device 110 being located at the client browser device The communication between 102 and the application server 104 is intermediate. Therefore, after the client browser connects the intermediary device, the intermediary device is then connected. To the application server, just like two connections. Each connection has a source IP address from the requester.

Because the intermediary device relays messages between the client browser and the authentication server, the first factor authentication of the browser 102 (using the user's user identification and password) will succeed. In addition, the second factor authentication between the browser 102 and the authentication server 106 on the independent secure channel will also be successful. Then, any subsequent communication between the client browser 102 and the application server 104 is revealed, and because the intermediary device 110 can perform almost any action on behalf of the client browser 102, including, for example, SSL protocol information modification, fraudulent The risk still exists.

3 shows a schematic diagram of IP Address Secure Multi-Channel Authentication (IPAS-MCA) in accordance with one embodiment of the present invention. In the example of FIG. 3, the steps of the IPAS-MCA technique are described, although in the example of FIG. 3 there is no fraudulent intermediary device. Here, the case where there is a middleman device will be discussed in connection with FIG.

Referring back to Figure 3, first the client browser 302 contacts (330) the application server 304 to request authentication. At this stage, authentication typically uses a conventional combination of user identification and password. In addition, application server 304 also pays attention to the source IP address of the received packet. Record the source IP address. In the example of FIG. 3, since there is no intermediary device, the source IP address will be the IP address of the client browser 302.

If the authenticated user is considered to be a valid user based on the first factor, it is determined whether the user of the client browser 302 is a subscriber of the multi-channel authentication system. The decision may be made by the authentication server 306 by, for example, checking the identity of the user for its subscriber profile (which is forwarded (332) by the application server 304 to the authentication server 306). In addition, source IP address information recorded by application server 304 is passed (332) to authentication server 306.

If it is determined that the user is a subscriber of the multi-channel authentication system, the authentication server 306 sends (334) instructions (eg, in the form of HTML code) to the client browser 302 via the application server 304 for purposes of performing further authentication, to The client browser 302 is instructed to establish a secure communication channel with the authentication server 306.

Utilizing the instructions provided by authentication server 306 (which is sent to client browser 302 via application server 304), client browser 302 then (using, for example, AJAX technology or similar techniques) establish (336A/336B) to The communication channel of the authentication server 306. Through the additional communication channel, the client browser 302 and the authentication server 306 can perform further authentication.

In general, additional authentication may require information that is only known to the user and/or that is specific to the communication device that is registered with the multi-channel authentication system as belonging to the user and authorized to perform the transaction. As mentioned, even if the user identification and password are compromised, the fraudster cannot complete the authentication because the additional authentication with the authentication server requires additional information specific to the user and/or the authorized user device.

In addition, the authentication server 306 checks the source IP address from the data packet received from the client browser 302 to determine that the secure communication session between the client browser 302 and the authentication server 306 is in the secondary user. Whether the IP address in the data packet received by the browser 302 and the IP address forwarded by the application server 304 (which is reflected by the application server during the first factor authentication between the client browser 302 and the application server 304) The source IP address in the data packet received by 304 matches. If the two IP addresses match, then as in the case of the example of Figure 3, the authentication is considered successful because there is no intermediary device.

4 illustrates IP address secure multi-channel authentication in accordance with one embodiment of the present invention. Schematic diagram of (IPAS-MCA). In the example of FIG. 4, the intermediary device 420 is fraudulently inserted in the communication stream between the client browser 402 and the application server 404. In general, the intermediary device 420 can first establish communication with the client browser 402 using techniques such as phishing to fool the user of the browser browser 402 to believe that the user of the browser browser 402 is working with the application. The server 404 communicates. Once communication between the client browser 402 and the intermediary device 420 is established, the intermediary device 420 contacts the application server 404 and opens a communication channel.

Subsequent communication between the client browser 402 and the application server 404 is relayed by the intermediary device 420.

The application server 404 requests authentication of the client browser 402, and the request is relayed by the intermediary device 420 to the client browser 402. As mentioned, at this stage, as is traditionally the authentication typically uses the user identification and password combination again. After the intermediary device 420 relays the request, the client browser 402 responds to the request with a user identification/password combination. The intermediary device 420 relays the user identification/password to the application server 404.

The application server 404 also notices the source IP address of the received packet. Since the data packet arrives from the intermediary device 420, the source IP address associated with the intermediary device 420 is recorded.

If the user is considered to be a valid user based on the user identification/password combination, it is determined whether the user of the client browser 402 is a subscriber of the multi-channel authentication system. The decision may be made by the authentication server 406 by, for example, checking the identity of the user for its subscriber profile (which is forwarded (432) by the application server 404 to the authentication server 406). In addition, the source IP address information to be recorded by the application server 404 (in this example it is reflected from the communication) The IP address of the middleman device 420 of 430B is passed (see reference arrow 432) to the authentication server 406.

If it is determined that the user is a subscriber of the multi-channel authentication system, the authentication server 406 sends (434A) an instruction (eg, in the form of an HTML code) to the client browser 402 via the application server 404 for the purpose of performing further authentication to indicate The client browser 402 establishes a secure communication channel with the authentication server 406. These instructions are relayed (434B) by the intermediary device 420 to the client browser 402.

Using the instructions provided by the authentication server 406 (which is sent to the client browser 402 via the application server 404), the client browser 402 then establishes a communication channel (436A/436B) to the authentication server 406. Through the communication channel, the client browser 402 and the authentication server 406 can perform further authentication. Note that the instructions from the authentication server 406 may include a challenge/response that the intermediary device 420 cannot respond to because the intermediary device 420 does not have a shared secret. In this case, the intermediary device 420 passes the instructions from the authentication server 406 to the client browser 402 to allow the client browser 402 to answer the query/response. The client browser 402 then establishes a communication channel with the authentication server 406 as instructed.

In addition, the authentication server 406 checks the source IP address from the data packet received from the client browser 402 (from the communication specified by reference numeral 436A) to determine the client browser 402 and the authentication server. In the secure communication session between 406, whether the IP address in the data packet received from the client browser 402 and the IP address forwarded by the application server 404 are reflected in the client browser 402 and the application server The first factor authentication between 404 matches the source IP address in the data packet received (430B) by the application server 404.

Because the IP address recorded by the application server 404 and passed to the authentication server 406 reflects the IP address of the intermediary device 420, the IP address does not match the IP address of the client browser, which is browsed by the client. The IP address of the device is obtained by the authentication server 406 from communication between the client browser 402 and the authentication server 406. In this case, the authentication will fail.

As can be appreciated from the above, embodiments of the present invention extend the security provided by multi-channel authentication techniques by further implementing protection against man-in-the-middle attacks. If the user identification/password combination is stolen, the multi-channel authentication scheme can prevent subsequent authentication by the fraudster because the fraudster cannot have the information needed for the second authentication on the independent secure channel (whether it is explicitly provided by the user or Automatically provided by the communication device through which the user performs authorization for online transaction authentication). More importantly, if the intermediary device is fraudulently inserted into the communication path between the client browser and the application server, the IPAS-MCA technology can detect the presence of such a fraudulent intermediary device by comparing the IP addresses. And prevent authentication and subsequent fraudulent transactions.

Further information herein incorporated by reference is provided by the claims.

Although the invention has been described in terms of several preferred embodiments, modifications, substitutions and equivalents are possible within the scope of the invention. It should also be noted that there are many alternative ways of implementing the methods and apparatus of the present invention. Although a plurality of examples are provided herein, it is intended that the examples are illustrative and not restrictive.

102‧‧‧User Browser

104‧‧‧Application Server

106‧‧‧Authentication server

302‧‧‧User Browser

304‧‧‧Application Server

306‧‧‧Authenticated server

332‧‧‧IP address from 330 communication

402‧‧‧User Browser

404‧‧‧Application Server

406‧‧‧Authenticated server

432‧‧‧IP address from 430B communication

Figure 1 illustrates a typical multi-channel authentication scheme in which a client browser utilizes both an application server and an authentication server for authentication.

Figure 2 shows the presence of a man-in-the-middle device, the middle The human device has been implemented by the fraudster for the purpose of committing fraud to the user.

3 shows a schematic diagram of an IP Address Secure Multi-Channel Authentication (IPAS-MCA) scenario in accordance with one embodiment of the present invention.

4 shows a schematic diagram of an IP Address Secure Multi-Channel Authentication (IPAS-MCA) scenario whereby a man-in-the-middle attack is defeated in accordance with one embodiment of the present invention.

102‧‧‧User Browser

104‧‧‧Application Server

106‧‧‧Authentication server

Claims (20)

A computer implemented method for multi-factor authentication of a user using an application server and an authentication server, the user interacting with the application server and the authentication server, the user utilizing a user browser program Communicating with at least one of an application server and the authentication server, the method comprising: authenticating the user with a first factor authentication certificate using the application server; from the application server to the authentication server Providing a first source IP address associated with the request for the authentication using the first factor authentication certificate; instructing the user to establish an independent communication between the user browser program and the authentication server Channel to perform additional authentication; comparing the first source IP address with a second source IP address associated with communication from the user to the authentication server utilizing the independent communication channel; and if If the first source IP address does not match the second source IP address, the user's authentication fails. The method of claim 1 wherein said first factor authentication certificate comprises at least a user identification and a password. The method of claim 1 further comprising determining whether said user is more than instructing said user to establish said independent communication channel between said user browser program and said authentication server to perform additional authentication Subscriber to the factor authentication service. The method of claim 1 wherein said additional authentication comprises utilizing a shared secret for authentication between said authentication server and said user browser program. The method of claim 4 wherein said shared secret comprises a known fact. The method of claim 5 wherein said known fact is registered by said user It is provided during the use of an out-of-band communication channel. The method of claim 6 wherein said out of band communication channel comprises a voice call. The method of claim 1 wherein said additional authentication is performed encrypted. The method of claim 1 wherein said additional authentication is two-way authentication between said authentication server and said user browser program. The method of claim 1 wherein said instructing said user to establish said independent communication channel between said user browser program and said authentication server to perform additional authentication involves AJAX technology. The method of claim 1 wherein said instructing said user to establish said independent communication channel between said user browser program and said authentication server uses HTML. A computer implemented method for multi-factor authentication of a user using an application server and an authentication server, the user interacting with at least one of the application server and the authentication server using a user browser program The method includes receiving, from the application server, a first source IP address associated with an authentication request from the user browser program to the application server; receiving a request from the user browser program to utilize independence a communication channel to perform additional authentication between the user browser program and the authentication server, the independent communication channel and a communication channel used to communicate between the application server and the authentication server Independently comparing the first source IP address with a second source IP address associated with the request to perform the additional authentication between the authentication server and the user browser program; If the first source IP address does not match the second source IP address, the authentication of the user fails. The method of claim 12 wherein said authenticating between said user browser program and said application server comprises authenticating with a first factor certificate. The method of claim 12 wherein said first factor authentication certificate comprises at least a user identification and a password. The method of claim 12 further comprising determining whether said user is instructed said user to establish said independent communication channel between said user browser program and said authentication server to perform said additional authentication It is a subscriber to the multi-factor authentication service. The method of claim 12 wherein said additional authentication comprises utilizing a shared secret for authentication between said authentication server and said user browser program. The method of claim 16 wherein said shared secret comprises a known fact. The method of claim 17 wherein said known fact is provided by said user utilizing an out-of-band communication channel during registration. The method of claim 12 wherein said additional authentication is two-way authentication between said authentication server and said user browser program. The method of claim 12 wherein said additional authentication is performed encrypted.