GB2582326A

GB2582326A - A method of mutual authentication

Info

Publication number: GB2582326A
Application number: GB1903736.5A
Authority: GB
Inventors: Underwood Phillip
Original assignee: Securenvoy Ltd
Current assignee: Securenvoy Ltd
Priority date: 2019-03-19
Filing date: 2019-03-19
Publication date: 2020-09-23
Anticipated expiration: 2039-03-19
Also published as: GB2582326B; GB201903736D0

Abstract

An authentication method between a user 101 and a resource server 104 comprises sending a first authentication factor, possibly from a first user device to the resource server, via a first communication channel, sending a second authentication factor, possibly from an authentication server 107 to the first user device or a second user device 105, via a different second channel, and sending a third authentication factor, possibly from the first/second user device to the authentication server, via the second channel. The second factor may be sent once the first factor is authenticated by the service provider, and the third may be sent in response to the authentication of the second. Once the third factor is authenticated, authentication information may be sent from the authentication server to the resource server, which may send an access token to the user. The second and third authentication factors may be one-time passwords (OTPs), whereby the authentication server and first/second user device are mutually authenticated. Authentication factors may also be user IDs, passwords or biometric data. Communication through the second channel may be by means of Unstructured Supplementary Service Data (USSD), sent using a GSM mobile device and a USSD gateway (206, fig. 3).

Description

A METHOD OF MUTUAL AUTHENTICATION

FIELD OF THE INVENTION

The present invention relates to a method of authentication. Specifically, the invention relates to a method of authenticating a user in a multi-factor authentication environment.

BACKGROUND OF THE INVENTION

In all authentication processes, a user requesting access to a resource must submit their authentication factor over, for example, a HTTP channel. The entity which controls access to the resource receives the authentication factor through the HTTP channel and checks it against a database to ensure that the user is genuine.

In a multi factor authentication approach, additional authentication credentials provided via a separate device and are submitted over the same HTTP channel. That is, a User ID, password and second factor are all submitted over the same channel.

These approaches are open to a man in the middle (MITM) attack. In such an attack, a disingenuous entity places itself on the communication channel between a user and an authentication service. In this manner, the disingenuous entity receives the data sent by the user and presents it to the authentication service in an attempt to fool the authentication service. Similarly, any data sent by the authentication service is presented to the user, as if it had come directly from the authentication service. In this manner, the disingenuous entity merely needs to gain entry into the one communication channel in order to achieve access to the user's resource.

SUMMARY OF THE INVENTION

A first aspect of the present invention provides a method of authentication between a user and a resource server, comprising the steps of: sending, to the resource server and via a first communication channel, a first authentication factor; receiving, via a second communication channel, a second authentication factor, the second communication channel being different from the first communication channel; authenticating the second authentication factor; and in response to a positive authentication of the second authentication factor, sending, via the second authentication channel, a third authentication factor.

The step of sending the first authentication factor may be performed by a first user device.

The second authentication factor may be received by a second user device, different from the first user device.

The step of sending the third authentication factor may be performed by the second user device.

The second authentication factor may be received via an authentication server, the authentication server being different from the resource server.

The third authentication factor may sent to the authentication server.

The second communication channel may be Unstructured Supplementary Service Data, USSD.

A second aspect of the present invention provides a device for authentication between a user and a resource server, the device comprising computer-implemented instructions that, when executed, cause the device to: send, to the resource server and via a first communication channel, a first authentication factor; receive, via a second communication channel, a second authentication factor, the second communication channel being different from the first communication channel; authenticate the second authentication factor; and in response to a positive authentication of the second authentication factor, send, via the second authentication channel, a third authentication factor.

A third aspect of the present invention provides a method of enabling authentication between a user and a resource server, comprising the steps of: receiving an indication that a first authentication factor, received via a first communication channel, has been positively authenticated; sending, via a second communication channel different from the first communication channel, a second authentication factor; receiving, via the second communication channel, a third authentication factor; authentication the third authentication factor; and sending, in response to a positive authentication of the third authentication factor, authentication information to the resource server.

Wherein the step of receiving an indication that the first authentication factor has been positively authenticated may further comprise the steps of: receiving, via a first communication channel, the first authentication factor; and authenticating the first authentication factor.

The first authentication factor may be received from a first user device.

The second authentication factor may be sent to a second user device, different from a first user device used to send the access request.

The third authentication factor may be received from the second user device.

A fourth aspect of the present invention provides a device for authentication between a user and a resource server, the device comprising instructions that, when executed, cause the device to: receive an indication that a first authentication factor, received via a first communication channel, has been positively authenticated; send, via a second communication channel different from the first communication channel, a second authentication factor; receive, via the second communication channel, a third authentication factor; authenticate the third authentication factor; and send, in response to a positive authentication of the third authentication factor, authentication information to the resource server.

A fifth aspect of the present invention provides a system for authentication between a user and a resource server, the system comprising: a first user device, arranged to send a first authentication factor to the resource server via a first communication channel; the resource server, arranged to authenticate the first authentication factor; an authentication server, arranged to send a second authentication factor to a second user device via a second communication channel, in response to a positive authentication of the second authentication factor; and a second user device, arranged to authenticate the second authentication factor and, in response to a positive authentication of the second authentication factor, send a third authentication factor to the authentication server via the second communication channel, wherein the authentication sever is further arranged to authenticate the third authentication factor.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects of the present invention will become apparent from a consideration of the following description and accompanying drawings, in which: FIGURE 1 shows a system diagram of an authentication system within an embodiment of the present invention; FIGURE 2 shows a system flow diagram of an authentication process between a user and a service provider within an embodiment of the present invention; FIGURE 3 shows a system diagram of the system of FIGURE 1 with a USSD implementation; FIGURE 4 shows a system flow diagram of the authentication process of FIGURE 2, with a USSD implementation; FIGURE 5 shows a flow diagram outlining a method of mutual authentication performed by an authentication service within an embodiment of the present invention; and FIGURE 6 shows a flow diagram outlining a method of mutual authentication performed by a user within an embodiment of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention provides a system in which a user request to access a resource is authenticated across two different communication channels. The user provides a first authentication factor to a resource server via a first channel. The resource server then causes a second authentication factor to be sent to the user via a second channel. In response to a positive authentication of the second factor by the user, the user supplies a third authentication factor, via the second channel, thus confirming that the provision of the first authentication factor was genuine.

The present invention is described with reference to a multi factor authentication system.

Figure 1 shows a system comprising a user 101, a service provider 102 and an authentication entity 103. The user 101 is in possession of multiple devices which are capable of requesting access to a resource provided by the service provider 102. For example, the user 101 may have a mobile device 105 and a computer 110, each with access to the Internet via, for example, a broadband Internet connection. The mobile device 105 may also have access to the Internet as well as a GSM network.

The service provider 102 interacts with other entities by means of a resource server 104.

The resource server 104 provides access to a resource, for example, a network, a database, a program etc. The resource server 104 is accessed by means of a HTTP channel using the Internet.

In order to assist the service provider 102 in authenticating entities wishing to access the resource, the authentication entity 103, via means of an authentication server 107, provides an alternative communication channel between the resource server 104 and the user 101. For example, a communication channel between the authentication server 107 and the resource server 104 may be formed of, for example, a dedicated electronic communication channel, a standard public Internet connection etc. Further, the communication channel between the authentication server 107 and the user 101 may be formed of, for example, a GSM connection to the user's mobile device 105.

In general, there are several ways that a user can prove (with evidence) that they are who they say they are. Each type of authentication factor can be roughly defined as being one of three factors: something you know (e.g., a user ID, a password etc.); something you own (e.g., a mobile phone, a token generator etc.); and something you are (e.g., biometric information such as a finger print or facial recognition). In multi factor authentication systems, a user attempting to gain access to a resource is asked to provide at least two different factors in order to confirm that the access attempt is genuine.

In this sense, an authentication factor may not be the evidence itself, but an indication that the required evidence has been provided. For example, a user may not provide an image of their fingerprint to an entity requesting authentication. Instead, a fingerprint scanning device may provide confirmation that a fingerprint scanned by the device matches a fingerprint image in a local database. This confirmation may form an authentication factor which is sent between entities. Alternatively, a user may input a secret password/PIN at a local device. The local device may encrypt the secret password/PIN and send the encrypted information to another entity for comparison with a stored encrypted password/PIN.

As such, although authentication factors are generally considered to be one of: something you know; something you own; or something you are, in the present context, an authentication factor may also include data indicating that such information has been provided to an entity capable of authenticating an authentication factor.

With reference to Figure 2, in a first step, the user 101 sends a request for access to a resource via a computer 110. In response, the resource server 104 prompts the user 101 to provide a first authentication factor. The user 101 then inputs a user ID and an associated password at a log in page of, for example, a website associated with the resource server 104. The user ID and the password represent the first authentication factor to be used in the authentication process, in that they define something which is known by the user 101. The log in page passes the user ID and the password on to the resource server 104 associated with the service provider 102. The resource server 104 checks the user ID and the password against information stored within the resource server 104 in order to confirm that the first authentication factor is valid.

If the user ID and password do not match the information stored in the resource server 104, then the user 101 is denied access to the resource. A corresponding message is presented to the user at the website, indicating to the user that the user ID and/or password is incorrect.

If the user ID and password do match the information stored in the resource server 104, then the resource server 104 initiates authentication of a further authentication factor of the user 101. In the present example, the further authentication factor requires the user 101 to show that they are in possession of a mobile phone 105 associated with the user 101, i.e., something they own. However, it is to be understood that other such authentication factors may be used, for example, by means of a fingerprint or facial recognition.

In order to initiate authentication of the further authentication factor, the resource server 104 indicates to an authentication server 107 of the authentication entity 103 that the user 101 has requested access to a resource. Information sent from the resource server 104 to the authentication entity 103 only needs to include information identifying the user 101, such as the user ID. The user's password does not need to be provided to the authentication entity 103, although it may be provided in certain circumstances.

Once the authentication entity 103 has received the relevant information from the resource server 104, the information is checked against a locally stored database to determine a means of contacting the user 101. In this example, the user ID is matched to a mobile telephone number associated with the user's mobile phone 105. However, it is to be understood that the user 101 may be contacted in other ways, such as by using a MSISDN/IMEI number, email address or IP address.

The locally stored database also contains information indicating how the authentication entity 103 should identify itself to the user 101. For example, in order to identify itself, the authentication entity 103 may provide a unique code, which has been previously agreed between the user 101 and the authentication entity 103. Alternatively, the user 101 and the authentication entity 103 may agree upon an algorithm for determining a one-time password (OTP). The authentication entity 103 may then perform the algorithm in advance of contacting the user's mobile phone 105. This process allows the authentication entity 103 to provide a second authentication factor to the user 101, in order to identify itself (something the authentication entity 103 knows).

Algorithms for producing OTPs may use a large array of inputs in order to ensure that it is not possible to guess them. For example, the algorithm may require the MSISDN/IMEI number of the user's mobile device 105, the current time or some other value as an input. Some of these values may only be known to the user and anyone who the user has chosen to share the value with. As such, even if a disingenuous entity knows what kind of values are required for the OTP inputs, they may not be able to obtain knowledge of the specific values.

As mentioned above, OTPs may be produced according to algorithms which have a time-based input. In this manner, one of the inputs for producing an OTP may be a value representing the local time at which the algorithm was performed. The time-based input may have an accuracy of, for example, 1 minute, such that OTPs produced one minute apart would be different from each other. Producing OTPs in this manner enables a further security feature, in that an authentication process can require the production of multiple OTPs which are temporally consecutive to one another. In this manner, a disingenuous entity cannot simply 'guess' one OTP in order to gain access to a resource, but must also provide the next logical OTP in accordance with the algorithm. The probability of guessing two consecutive OTPs being substantially lower than guessing one OTP.

For the authentication entity 103 to initiate authentication of the user's further authentication factor, the authentication entity 103 sends a message to the mobile phone 105 comprising: the locally generated second authentication factor (e.g., a first OTP); a request for a third authentication factor (e.g., a second OTP); and a message indicating that an access request has been made using the user's ID and password.

Upon receiving the message from the authentication entity 3, the user 1 will be informed that an access request has been made. If the user 1 is satisfied that an attempt to access the resource is genuine, they will proceed to authenticate the second authentication factor (the first OTP) received from the authentication entity 103. However, if the access request did not originate from the user 101, then the user 101 may ignore the message, or attempt to contact the service provider 102 in order to indicate that a malicious attempt to gain access to a resource is in progress.

The mobile phone 105 may authenticate the first OTP by performing the same algorithm as the authentication entity 103, and then comparing the result with the received first OTP. If the results do not match, then the user 101 can ignore the first OTP. If the results match, then the user 101 can be certain that the authentication entity 103 sent the first OTP.

Once the mobile phone 105 has confirmed that the authentication entity 103 sent the first OTP, the mobile phone 105 then produces a third authentication factor (the second OTP) in order to authenticate itself to the authentication entity 103. The second OTP may be produced according to the same algorithm as the first OTP, but with a minor modification (e.g., by modifying a time-based variant in the algorithm). Alternatively, the second OTP may be produced according to an algorithm which is substantially different from that used to produce the first OTP.

Of course, as with the first OTP, the third authentication factor does not need to be a onetime password. The third authentication factor may be a predetermined response code, or biometric data of the user 101 etc. Once produced, the mobile phone 105 sends the second OTP back to the authentication entity 103, at which point the authentication entity 103 begins an authentication process. As with the first OTP at the mobile device 105, the authentication entity 103 may authenticate the second OTP by performing the same algorithm as the mobile phone 105 and comparing the result with the second OTP.

If authentication of the second OTP is successful, the authentication entity 103 informs the service provider 102 that the access request is genuine and has been authenticated.

The service provider 102 will then enable access to the resource. This may be achieved, for example, by generating an access token and then sending the token to the user 101.

If authentication of the second OTP fails, then the authentication entity 103 informs the service provider 102 that the access request is disingenuous. The service provider 102 will then deny access to the resource.

With reference to Figures 3 and 4, there is shown a further embodiment of the invention in which the authentication entity 203 communicates with the user 201 and the mobile phone 205 through means of Unstructured Supplementary Service Data (USSD).

USSD is a GSM protocol which enables the transfer of small data volumes over the signalling channel of the GSM network. The signalling channel is always operational as it provides GSM information, SMS and assigned services to a user's GSM account. As long as a user 201 has a GSM signal, USSD operation can occur as the mobile phone 205 does not need an active data connection, not does it incur SMS fees.

In order to enable USSD operation, two components are required: a GSM device (mobile phone 205); and a USSD gateway 206.

USSD gateways 6 are available directly through a USSD provider 208, such as a Telephone Company (Telco) provider, however, these are limited to base functions for pre-paid services, such as top-up of credit on a GSM account, accessing balance and other basic user requests.

Third party companies and mobile-value added services can also provide additional capability via a dedicated USSD connection and backend application programming interface (API).

USSD can support a network initiated or a user initiated request. For ease of use in user authentication and transaction approval, a network initiated request is discussed with reference to the present invention.

When using a network initiated request, the user 201 is contacted on the GSM network using the MSISDN/IMEI number of the mobile phone 205. This enables a real-time connection within which the user 1 is challenged to provide a response.

Basic mobile phones 205 enable a user to provide simple responses such as entering a number in response to a question (e.g., 1 = yes, 2 = no, 3 = ignore), or entering a PIN, password or authentication code. In some cases, a basic mobile phone 205 may be sufficient for the required interaction.

However, mobile phones 205 which are smart phones, especially those running the AndroidTM operating system, are enabled to use applications for interactions with a USSD session directly. This allows the use of a more mature user interface which is not limited to textual inputs and responses.

For example, a smartphone USSD interface may enable a user 201 to provide responses such as: typing a specific response (e.g., 'yes', 'no' or 'discard'); depressing an appropriately labelled button (e.g., 'alert'); entering a PIN, password or authentication code; or providing a challenge-response.

When entering a PIN, password, authentication code of challenge-response, a user input may then be run through the application which can apply a salt or other unique hash that is then provided as an output to be sent via the USSD gateway 206.

The USSD gateway 206 is configured to interact with the application and submit the responses to the authentication entity 203. As USSD allows for multiple responses, it can be configured to allow a signed transaction approval via a digital certificate.

Figure 3 shows a system comprising a user 201, a service provider 202, an authentication entity 203, and USED provider 208. As described above with reference to Figure 1, the user 201 is in possession of multiple devices which are capable of requesting access to a resource provided by the service provider 202. For example, the user 201 may have a mobile device 205 and a computer 210, each with access to the Internet via, for example, a standard home/business Internet connection. The mobile device 205 may also have access to the Internet via other means, such as a GSM network.

The service provider 202 interacts with other entities by means of a resource server 204. The resource server 204 provides access to a resource, for example, a network, a database, specific information etc. The resource server 104 is accessed by means of a HTTP channel using the Internet.

In order to assist the service provider 202 in authenticating entities wishing to access the resource, the authentication entity 203, via means of an authentication server 207, provides an alternative communication channel between the resource server 204 and the user 201. For example, a communication channel between the authentication server 207 and the resource server 204 may be formed of, for example, a dedicated electronic communication channel, a standard Internet connection etc. However, in contrast to the system of Figure 1, the authentication entity 203 does not communicate with the user 201 directly. Instead, in this embodiment, the authentication server 207 uses a USSD gateway 206 which, in turn, uses the USSD functionality of the GSM network to send data to the user's mobile phone 205. Specifically, the USSD provider 208 provides a USSD API 209 which supports the ability of the authentication server 207 to access the USSD gateway 206.

As shown in Figure 4, embodiments comprising a USSD gateway 206 are similar to the embodiments of Figure 2. The initial interactions between the user 201 and the service provider 202 remain the same, in that a user 201 provides a first authentication factor which is authenticated by the service provider 202.

Further, similar to the above, upon a positive authentication of the first authentication factor, the service provider 202 proceeds by contacting the authentication entity 203 in order to initiate further authentication.

However, instead of communicating with the user's mobile phone 205 directly, the authentication entity 203 communicates using a USSD API 209 which forwards data through the USSD gateway 206. In this manner, the authentication entity 203 provides the MSISDN/IMEI number of the user's mobile phone 205 via the USSD API 209, in order that a communication channel can be created.

The mobile phone 205 receives the first OTP (or other second authentication factor) from the USSD gateway 206 and performs authentication as per the above. The mobile phone 205 then produces the second OTP (or other third authentication factor) and sends it back to the USSD API 209 via the USSD gateway 206. The USSD API 209 then sends the second OTP on to the authentication entity 203 for authentication.

As with the above, the authentication entity 203, upon positive authentication, notifies the service provider 202 that the authentication was successful.

The advantage of using USSD lies in the difficulty in obtaining access to a USSD gateway 206. As USSD gateways 206 are run by few companies wherein bandwidth is limited, entities with access to those gateways 206 can be assumed to be legitimate entities without disingenuous intentions.

With reference to Figure 5, there is shown a flow diagram detailing a method as performed by the authentication entity 3 which corresponds with any of the embodiments described above. In step 501, the authentication entity 103 receives a request to authenticate a user 101. The request is received from the service provider 102, via a communication channel between the service provider 102 and the authentication entity 103. Upon receipt, the authentication entity 103 uses a user ID stored within the request to find contact information related to the user 101.

At step 502, the authentication entity 103 sends the first OTP (the second authentication factor) to the mobile phone 105 of the user 101. The first OTP is sent via a communication channel which is separate from the communication channel between the authentication entity 103 and the service provider 102. For example, the first OTP may be sent via GSM (such as USSD), HTTP or other communication protocol.

At step 503, the authentication entity 103 receives a second OTP (third authentication factor) from the mobile phone 105. The authentication entity 103 may, at this point, assume that it has been successfully authenticated by the mobile phone 105. The second OTP is sent via the same communication channel as the first OTP.

At step 504, the authentication entity 103 authenticates the second OTP. As mentioned above, in this manner, the authentication entity 103 may perform the same algorithm as the mobile phone 105 and compare the result with the second OTP. Alternatively, the authentication entity 103 may compare the second OTP with a predefined value.

Assuming that the authentication is successful, at step 505, the authentication server sends confirmation to the service provider that the user 101 has been authenticated. This confirmation is sent via the same communication channel through which the initial request was received.

Referring now to Figure 6, there is shown a flow diagram detailing a method as performed by the user 101, via a mobile phone 105. The method of Figure 6 applies to any of the embodiments described above.

At step 601, the user 101 requests access to a resource. The access request may be performed by any device, for example, a computer. The request is made over a first communication channel (e.g., HTTP).

At step 602, the user 101 receives a request for a first authentication factor. The request is received via the first communication channel.

At step 603, the user provides the first authentication factor (e.g., a user ID and password), via the first authentication channel.

Assuming that the user ID and password match the information stored within a database of the service provider 102, at step 604, the user will receive a message including: an indication that an access request has been made; a second authentication factor; and a request for a third authentication factor. The message is received at the user's mobile phone 105, via a second communication channel different from the first communication channel.

Upon receipt of the message, the user 101 will read the message to determine whether the access request is correct. Of course, as the user 101 has requested access in steps 601 and 602, it is assumed that the request is genuine. However, if the request is not genuine, the user 101 may ignore the message or contact the service provider to inform them that a disingenuous access request is in progress.

At step 605, the mobile phone 105 authenticates the second authentication factor. This may be actively initiated by the user 101, in order to ensure that the user 101 is comfortable that the access request is genuine. In order to authenticate the second authentication factor, the mobile phone 105 may performed an algorithm to generate a corresponding key and then compare the two values. Alternatively, the mobile phone 105 may compare the second authentication factor against a predetermined value stored within the mobile phone 105.

At step 606, assuming that the second authentication factor is positively authenticated, the mobile phone 105 prepares a third authentication factor and sends it back via the second communication channel.

Of course, in communicating via the second communication channel, the user 101, 201 may be communicating directly with the authentication server 107 or via the USSD gateway 206. In either case, the main steps performed by the user 101, 201 remains the same, in that the user 101, 201 receives a second authentication factor, authenticates it and responds by providing a third authentication factor.

The third authentication factor may be prepared using an algorithm corresponding to the second authentication factor. This may be modified slightly, in accordance with a time sequence or other such modification. Alternatively, the third authentication factor may comprise a predetermined value or biometric data of the user 101.

Once the third authentication factor has been authenticated, the user 101 is granted access to the resource.

Although embodiments of the invention described above state that the service provider 102 and the authentication entity 103 are separate entities, it is to be understood that this is a preferred embodiment. In other embodiments, the service provider 102 and the authentication entity 103 may be the same entity.

Further, although embodiments of the invention described above detail that the user actions are performed using a computer and a mobile device, it is to be understood that the user may perform the necessary actions using any suitable device with a suitable communication channel. Further, the user may perform the necessary actions all within the same device, so long as communication of the first authentication factor is performed via a separate communication channel than that used for the second and third authentication factors.

It is to be appreciated that the communication channels may be wired, wireless or any other type of communication channel. Further, the signal transmitted by the communication channel may be electrical, or alternatively, there may be a transmitter and a receiver arrangement, such that the information may be sent via Bluetooth RF signal, WiFi ® or any other type of wireless transmission means.

The skilled person will also realise that steps of various above-described methods can be performed by programmed computers. Accordingly the above-mentioned embodiments should be understood to cover storage devices containing machine-executable or computer-executable instructions to perform some or all of the steps of the above-described methods. The embodiments are also intended to cover computers programmed to perform the steps of the above-described methods.

The functionality of the elements shown in the Figures can be provided using either dedicated hardware and/or software. The expressions "processing", "processing means" and "processing module" can include, but is not limited to, any of digital signal processor (DSPs) hardware, network processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), read only memories (ROMs) for storing software, random access memories (RAMs), and non-volatile storage.

The above embodiments describe one way of implementing the present invention. It will be appreciated that modifications of the features of the above embodiments are possible within the scope of the independent claims. For example, the methods described herein may be applied to any kind of computing device or user device. The features of the computer and mobile phone described herein are for example only and should not be seen as limiting to the claimed invention.

Features of the present invention are defined in the appended claims. While particular combinations of features have been presented in the claims, it will be appreciated that other combinations, such as those provided above, may be used.

Claims

CLAIMS1. A method of authentication between a user and a resource server, comprising the steps of: sending, to the resource server and via a first communication channel, a first authentication factor; receiving, via a second communication channel, a second authentication factor, the second communication channel being different from the first communication channel; authenticating the second authentication factor; and in response to a positive authentication of the second authentication factor, sending, via the second authentication channel, a third authentication factor.
2. The method of claim 1, wherein the step of sending the first authentication factor is performed by a first user device.
3. The method of claim 2, wherein the second authentication factor is received by a second user device, different from the first user device.
4. The method of claim 3, wherein the step of sending the third authentication factor is performed by the second user device.
5. The method of any of claims 1 to 4, wherein the second authentication factor is received via an authentication entity, the authentication server being different from the resource server.
6. The method of claim 5, wherein the third authentication factor is sent to the authentication server.
7. The method of any of claims 1 to 6, wherein the second communication channel is Unstructured Supplementary Service Data, USSD.
8. A device for authentication between a user and a resource server, the device comprising computer-implemented instructions that, when executed, cause the device to: send, to the resource server and via a first communication channel, a first authentication factor; receive, via a second communication channel, a second authentication factor, the second communication channel being different from the first communication channel; authenticate the second authentication factor; and in response to a positive authentication of the second authentication factor, send, via the second authentication channel, a third authentication factor.
9. A method of authentication between a user and a resource server, comprising the steps of: receiving an indication that a first authentication factor, received via a first communication channel, has been positively authenticated; sending, via a second communication channel different from the first communication channel, a second authentication factor; receiving, via the second communication channel, a third authentication factor; authenticating the third authentication factor; and sending, in response to a positive authentication of the third authentication factor, authentication information via the first communication channel.
10. The method of claim 9, wherein the step of receiving an indication that the first authentication factor has been positively authenticated further comprises the steps of: receiving, via a first communication channel, the first authentication factor; and authenticating the first authentication factor.
11. The method of claim 9 or 10, wherein the first authentication factor is received from a first user device.
12. The method of claim 11, wherein the second authentication factor is sent to a second user device, different from a first user device used to send the access request.
13. The method of claim 12, wherein the third authentication factor is received from the second user device.
14. The method of any of claims 9 to 13, wherein the second communication channel is Unstructured Supplementary Service Data, USSD.
15. A device for authentication between a user and a resource server, the device comprising computer-implemented instructions that, when executed, cause the device to: receive an indication that a first authentication factor, received via a first communication channel, has been positively authenticated; send, via a second communication channel different from the first communication channel, a second authentication factor; receive, via the second communication channel, a third authentication factor; authenticate the third authentication factor; and send, in response to a positive authentication of the third authentication factor, authentication information to the resource server.
16. A system for authentication between a user and a resource server, the system comprising: a first user device, arranged to send a first authentication factor to the resource server via a first communication channel; the resource server, arranged to authenticate the first authentication factor; an authentication server, arranged to send a second authentication factor to a second user device via a second communication channel, in response to a positive authentication of the second authentication factor; and a second user device, arranged to authenticate the second authentication factor and, in response to a positive authentication of the second authentication factor, send a third authentication factor to the authentication server via the second communication channel, wherein the authentication sever is further arranged to authenticate the third authentication factor.