CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of US Provisional Application 62/790,501 , entitled“Virtual U2F device,” filed January 10, 2019, whose disclosure is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to the field of computer security.

BACKGROUND

A relying party (RP) is a server providing access to a secure software application.

Fast Identity Online (FIDO) Universal 2nd Factor (U2F) is an example of an authentication standard (or“protocol”) that may he used to authenticate a client to an RP. In a U2F authentication flow, the RP generates a challenge, passes the challenge to the client, and looks up a public key. In response to receiving the challenge, the client transfers the challenge to a U2F device, referred to herein as a“token,” which stores a private key. Using the private key, the token generates a response to the challenge by signing the challenge. Subsequently, the token passes the response to the client, and the client then passes the response to the RP. Finally, the RP verifies the response with the public key.

International Patent Application Publication WO/2018/051236 to Kassner, whose disclosure is incorporated herein by reference, describes an apparatus comprising a communication interface and a processor. The processor is configured to obtain an NT Local Area Network Manager (NTLM) authentication token, which authenticates a client device to a service using an NTLM authentication protocol. The processor is further configured to, subsequently to obtaining the NTLM authentication token, receive, via the communication interface, from another processor that belongs to the client device, a challenge that was sent to the client device by the service in response to a request, from the client device, to access the service. The processor is further configured to, using the NTLM authentication token, compute a response to the received challenge, and to communicate the computed response to the client device, without exposing the NTLM authentication token to the client device. SUMMARY OF THE INVENTION

There is provided, in accordance with some embodiments of the present invention, an apparatus including a network interface and a processor. The processor is configured to receive, via the network interface, a challenge generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the processor. The processor is further configured to pass a request to sign the challenge, over a network, to an authenticating server that possesses the key, in response to receiving the challenge. The processor is further configured to receive from the authenticating server, subsequently to passing the request to the authenticating server, a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge. The processor is further configured to cause the response to be passed to the RP, in response to receiving the response.

In some embodiments, the protocol is a Universal 2nd Factor (U2F) protocol.

In some embodiments, the protocol is a Web Authentication (WebAuthn) protocol.

In some embodiments, the token includes a Universal 2nd Factor (U2F) token.

In some embodiments, the token includes a Client to Authenticator Protocol (CTAP) token.

In some embodiments, the processor is configured to pass the request to the authenticating server using a software agent that simulates the token.

In some embodiments,

the processor is configured to receive the challenge via a proxy server,

the processor is further configured to receive together with the challenge, from the proxy server, code that was received by the proxy server from the RP together with the challenge and was modified by the proxy server, and

tire processor is configured to pass the request to the authenticating server by executing the modified code.

In some embodiments, the processor is configured to pass the request to the authenticating server via the proxy server.

In some embodiments, the authenticating server is the proxy server.

There is further provided, in accordance with some embodiments of the present invention, a method including receiving, by a client, a challenge generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client. The method further includes, in response to receiving the challenge, passing a request to sign the challenge, over a network, to an authenticating server that possesses the key. The method further includes, subsequently to passing the request to the authenticating server, receiving, from the authenticating server, a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge. The method further includes, in response to receiving the response, causing the response to be passed to the RP.

There is further provided, in accordance with some embodiments of the present invention, a computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored. The instructions, when read by a processor, cause the processor to receive a challenge generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the processor. The instructions further cause the processor to pass a request to sign the challenge, over a network, to an authenticating server that possesses the key, in response to receiving the challenge. The instructions further cause the processor to receive from the authenticating server, subsequently to passing the request to the authenticating server, a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge. The instructions further cause the processor to cause tire response to be passed to tire RP, in response to receiving the response.

There is further provided, in accordance with some embodiments of the present invention, an apparatus including a network interface and a processor. The processor is configured to receive via the network interface, from a relying party (RP), a challenge directed to a client, the challenge having been generated by the RP in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client. The processor is further configured to cause a request to sign the challenge to be passed, over a network, to an authenticating server that possesses the key, in response to receiving the challenge. The processor is further configured to receive a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge, subsequently to causing the request to be passed to the authenticating server. The processor is further configured to cause the response to be passed to the RP, in response to receiving the response.

In some embodiments, the protocol is a Universal 2nd Factor (U2F) protocol.

In some embodiments, the protocol is a Web Authentication (WebAuthn) protocol. In some embodiments, the token includes a Universal 2nd Factor (U2F) token.

In some embodiments, the token includes a Client to Authenticator Protocol (CTAP) token.

In some embodiments, the processor is further configured to:

receive together with the challenge, from the RP, code configured to cause the client to pass the request to the token upon execution of the code by the client, and

modify the code to cause the client to pass the request to the processor upon execution of the code by the client,

the processor being configured to cause the request to be passed to the authenticating server by:

passing the modified code, together with the challenge, to the client, upon execution of the modified code by the client, receiving the request from the client, and

in response to receiving the request from the client, passing the request to the authenticating server.

In some embodiments, the processor belongs to the authenticating server.

There is further provided, in accordance with some embodiments of the present invention, a method including receiving by a proxy server, from a relying party (RP), a challenge directed to a client, the challenge having been generated by the RP in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client. The method further includes, in response to receiving the challenge, causing a request to sign the challenge to be passed, over a network, to an authenticating server that possesses the key. The method further includes, subsequently to causing the request to be passed to the authenticating server, receiving a response to the challenge, which was generated by tire authenticating server by using the key to sign the challenge. The method further includes, in response to receiving the response, causing the response to be passed to the RP.

In some embodiments, the authenticating server is the proxy server.

There is further provided, in accordance with some embodiments of the present invention, a computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored. The instructions, when read by a processor, cause the processor to receive, from a relying party (RP), a challenge directed to a client, the challenge having been generated by the RP in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client. The instructions further cause the processor to cause a request to sign the challenge to be passed, over a network, to an authenticating server that possesses the key, in response to receiving the challenge. The instructions further cause the processor to receive a response to the challenge, which was generated by tire authenticating server by using the key to sign the challenge, subsequently to causing the request to be passed to the authenticating server. The instructions further cause the processor to cause the response to be passed to the RP, in response to receiving the response.

There is further provided, in accordance with some embodiments of the present invention, an apparatus including a network interface and a processor. The processor is configured to receive, via the network interface, a request to sign a challenge, the challenge being directed to a client and having been generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client. The processor is further configured to request that a user of the client prove possession of at least one authentication factor, in response to receiving the request. The processor is further configured to generate a response to the challenge by using the key to sign the challenge and to cause the response to be passed to the RP, in response to the user proving possession of the authentication factor.

In some embodiments, the protocol is a Universal 2nd Factor (U2F) protocol.

In some embodiments, the protocol is a Web Authentication (WebAuthn) protocol.

In some embodiments, the token includes a Universal 2nd Factor (U2F) token.

In some embodiments, the token includes a Client to Authenticator Protocol (CTAP) token.

In some embodiments, the processor is configured to cause the response to be passed to the RP by passing the response to the client such that the client passes the response to the RP.

In some embodiments, the processor is configured to pass the response to the client via a proxy server.

In some embodiments, the processor is configured to receive the challenge from the RP by proxying between the client and the RP.

There is further provided, in accordance with some embodiments of the present invention, a method including receiving a request to sign a challenge, the challenge being directed to a client and having been generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client. The method further includes, in response to receiving the request, requesting that a user of the client prove possession of at least one authentication factor. The method further includes, in response to the user proving possession of the authentication factor, generating a response to the challenge by using the key to sign the challenge and causing the response to be passed to the RP.

There is further provided, in accordance with some embodiments of the present invention, a computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored. The instructions, when read by a processor, cause the processor to receive a request to sign a challenge, the challenge being directed to a client and having been generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client. The instructions further cause the processor to request that a user of the client prove possession of at least one authentication factor, in response to receiving the request. The instructions further cause the processor to generate a response to the challenge by using the key to sign the challenge and to cause tire response to be passed to the RP, in response to tire user proving possession of the authentication factor.

The present invention will be more fully understood from the following detailed description of embodiments thereof, taken together with the drawings, in which:

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic illustration of a system for authenticating to a relying party (RP), in accordance with some embodiments of the present invention;

Fig 2 is a schematic illustration of a flow of communication for authenticating to an RP, in accordance with some embodiments of the present invention;

Fig. 3 is a schematic illustration of a flow of communication for authenticating to an RP using a proxy server, in accordance with some embodiments of the present invention;

Fig 4 is a schematic illustration of an example algorithm for authenticating to an RP, in accordance with some embodiments of the present invention;

Fig. 5 is a schematic illustration of an example algorithm for proxying between a client, an authenticating server, and an RP, in accordance with some embodiments of the present invention; and

Fig. 6 is a schematic illustration of an example algorithm for facilitating authentication to an RP, in accordance with some embodiments of the present invention. DETAILED DESCRIPTION OF EMBODIMENTS

OVERVIEW

Some protocols for authenticating a client to a relying party (RP), such as the Universal 2nd Factor (U2F) protocol, require that the client sign a challenge generated by the RP. To sign the challenge, the client must use a private key provided by a token, such as a Universal Serial Bus (USB) token. ETsers allowed to authenticate to the RP are assigned different respective private keys.

A challenge, when using such protocols, is that a user may misplace or simply forget to carry the required token, leaving the user unable to access the application provided by the RP. Moreover, in a large organization, it may be difficult and/or expensive to provide a sufficient number of tokens to employees of the organization. Furthermore, some client devices may not support the use of certain tokens.

To address these challenges, embodiments of the present invention provide an authenticating server configured to store the respective private keys of a large number of users. Each client, or a proxy server on behalf of the client, is configured to forward challenges received from the RP to the authenticating server. Each challenge is forwarded along with relevant data that may be used, by the authenticating server, to identify the key required to sign the challenge and the user to whom the key is assigned. In response to receiving the challenge, the authenticating server may request, from the user, proof of possession of at least one authentication factor such as a password, a biometric factor (e.g., a fingerprint), or a device (e.g., a cellphone, such as a smartphone). In response to receiving the proof of possession from the user, the authenticating server may generate a response to the challenge by using the identified key to sign the challenge. Subsequently, the authenticating server may pass the response to the client or to the proxy server, and the response may then be passed to the RP.

Thus, the authenticating server, together with the relevant authentication factors, function as respective virtual tokens for multiple users, thereby extending the applicability of the authentication protocol by obviating the need for the dedicated tokens normally required by the protocol. Advantageously, the techniques described herein typically do not require any changes to the protocol or to the functionality of the RP.

SYSTEM DESCRIPTION

Reference is initially made to Fig. 1 , which is a schematic illustration of a system 20 for authenticating to a relying party (RP) 44, in accordance with some embodiments of the present invention.

Fig. 1 depicts a user 26 using a client device 22, referred to hereinbelow simply as a “client,” to request to authenticate to RP 44 for the purpose of accessing a secure software application. Client 22 may comprise a notebook computer, a desktop computer, a smartphone, or any other computing device. In some cases, client 22 belongs to a local area network (LAN) or a cloud computing environment. Client 22 comprises a network interface, such as a network interface controller 40, and a processor 42.

As further described below with respect to Fig. 2, in response to the request from the client, RP 44 generates a challenge in accordance with a protocol requiring that a (private) key, which is needed to sign the challenge, be provided by a token associated with the client. (In other words, the protocol requires that a token be associated with the client and that the token provide the key.) For example, the protocol may require that the key be stored on a physical token, such as a Universal Serial Bus (USB) token, connected to the client, or that the key be provided by a software token running on the client.

For example, the RP may generate a challenge in accordance with the U2F protocol or the Web Authentication (WebAuthn) protocol. The protocol may require that the client be associated with a U2F token or a Client to Authenticator Protocol (CTAP) token, such as a CTAP2 token.

Subsequently to generating the challenge, the RP communicates the challenge to the client. If a response to the challenge, generated by using the key to sign the challenge, is received by the RP, the RP authenticates the client (i.e., the RP accepts the client’s request to authenticate to the RP), and hence allows the client to access the secure application. Otherwise, the RP denies the client’s request.

System 20 comprises an authenticating server (AUTH SERVER) 28, comprising a network interface, such as a NIC 32, a processor 34, and a data storage 35, such as a hard drive or flash drive. Data storage 35 stores any keys belonging to user 26, typically along with the respective keys of multiple other users. In addition, data storage 35 may store any authentication policies for implementing the adaptive authentication techniques described hereinbelow with reference to Fig. 2, including, for example, a list of secure applications each user is allowed to access.

Each key is associated in data storage 35 with the user to whom the key is assigned. For example, each key may be associated with the user ID used by the user, the user’s name, the user’s cellphone number and/or another identifier of the user’s cellphone, and/or the user’s email address. In some embodiments, each key is further associated with a key handle, which, as further described below with reference to Fig. 2, may be used by authenticating server 28 to look up the key. Alternatively or additionally, each key may be associated with the secure application for which the key is required, e.g., by virtue of being associated with an application ID identifying the application and/or an identifier (e.g., an Internet Protocol (IP) address) of the RP providing access to the application.

As further described below with reference to Figs. 2-3, authenticating server 28 is configured to receive a request to sign the challenge, the challenge having been generated by RP 44 and directed to the client. In response to receiving the request, the authenticating server may request proof of possession of at least one authentication factor from user 26, either directly or using a third-party multi-factor authentication (MFA) provider. For example, the authenticating server may instruct an MFA provider to request that the user provide proof of possession of a password, a biometric factor, and/or a particular device, such as a cellphone (e.g., a smartphone). (The request for the proof of possession may be out-of-band - such as in cases in which the request is sent to the user’s cellphone - or in-band.) in response to receiving the proof of possession, the authenticating server generates a response to the challenge by using the appropriate key to sign the challenge, and then causes the response to be passed to the RP.

In some embodiments, system 20 further comprises a proxy server 24, comprising a network interface, such as a NIC 36, and a processor 38. In other embodiments, system 20 does not comprise proxy server 24; in such embodiments, the functionality of proxy server 24, described below with reference to Fig. 3, may be performed by authenticating server 28.

The respective processors of client 22, RP 44, authenticating server 28, and proxy server 24 are configured to communicate with each other, via their respective network interfaces, over a network 30, such as the Internet or any other computer network.

In general, each of the aforementioned processors may be embodied as a single processor, or as a cooperatively networked or clustered set of processors. In some embodiments, the functionality of each processor, as described herein, is implemented solely in hardware, e.g., using one or more Application-Specific Integrated Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs). In other embodiments, the functionality of at least one of the processors is implemented at least partly in software. For example, in some embodiments, the processor is embodied as a programmed digital computing device comprising at least a central processing unit (CPU) and random access memory (RAM). Program code, including software programs, and/or data are loaded into the RAM for execution and processing by the CPU. The program code and/or data may be downloaded to the processor in electronic form, over a network, for example. Alternatively or additionally, the program code and/or data may be provided and/or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory. Such program code and/or data, when provided to the processor, produce a machine or special-purpose computer, configured to perform the tasks described herein.

AUTHENTICATING TO THE RP

Reference is now made to Fig. 2, which is a schematic illustration of a flow of communication for authenticating to RP 44, in accordance with some embodiments of the present invention.

The flow' illustrated in Fig. 2 begins with a request 48 to authenticate to the RP, which the client sends, in an authentication-request-containing message 47, to the RP.

In response to receiving request 48, the RP generates a challenge 50 and passes challenge

50 to the client in a challenge-containing message 49. Challenge -containing message 49 may include, in addition to the challenge, code that, if executed by tire client, would cause the client to pass the challenge to the token required by the protocol. For example, for cases in which the challenge is generated in accordance with the U2F or WebAuthn protocol, challenge-containing message 49 may include a webpage containing, in addition to the challenge, a call to an application programming interface (API) for passing the challenge to the token. Alternatively or additionally, challenge-containing message 49 may contain other data associated with the challenge, such as the application ID of the secure application to which access is requested and/or a key handle identifying the key required to sign the challenge.

In response to receiving challenge-containing message 49, the client may validate any of the data contained therein. For example, for cases in which the application is accessed by pointing a web browser to a Uniform Resource Identifier (URI), the client may verify that the received application ID matches the URI, i.e., is derived from the URI as specified by the protocol.

Alternatively or additionally, in response to receiving message 49, the client communicates a request 45 to sign the challenge, in a sign-request-containing message 51, to the authenticating server. Typically, sign-request-containing message 51 contains, along with the challenge, data for identifying the key required to sign the challenge, the user to whom the key is assigned, and/or the application to which access is requested. For example, message 51 may contain the key handle identifying the key, the user ID of the user (under which request 48 was generated), the application ID of the application, and/or one or more properties of the RP, such as the IP address of the RP. Alternatively or additionally, message 51 may contain one or more properties of client 22, such as the IP address of the client, which may be used to identify the user ID. Other relevant data that may be included in message 51 include the URI pointed to by the browser running on the client, the Transport Layer Security (TLS) Channel ID over which the client is in communication with the RP, and/or the time at which request 48 was generated. Such data may be used for performing the adaptive authentication techniques described hereinbelow.

In general, the communication of request 45 to the authenticating server may be implemented using any suitable technique. For example, an application used by the client to request to authenticate to the RP, such as a web browser, may be modified to perform this functionality. In other words, a portion of code that, when executed by processor 42 (Fig. 1), causes the application to pass request 45 to the token required by the protocol may be replaced with another portion of code that causes the application to pass request 45 to the authenticating server.

Alternatively, a dedicated application, which is configured to communicate with the authenticating server in lieu of the token, may be used to request to authenticate to the RP.

As yet another alternative, a software agent (e.g., a driver or filter driver) that simulates the token and is installed on the client may be used to pass the request to the authenticating server. In particular, by virtue of the software agent simulating the token, the application used by the client to request to authenticate to the RP (e.g., a web browser) passes request 45 to the software agent (e.g , by executing the aforementioned code received from the RP) even without any special configuration of the application. In response to receiving the request, the software agent passes the request to the authenticating server.

Typically, the client communicates with the authenticating server over a secure encrypted TLS channel. In some embodiments, prior to the communication of any requests to the authenticating server over the channel, the authenticating server requires that the user prove the possession of a designated authentication factor, such as a password. Following receipt of the proof of possession, challenge -related communication between the client and the authenticating server may be enabled until the user logs out from the client. Alternatively, proof of a different respective authentication factor may be required to enable challenge-related communication for each RP or group of RPs.

In response to receiving message 51, the authenticating server identifies the key required to sign the challenge, the user to whom the key is assigned, and/or the application to which access is requested. These parameters are typically identified from data contained explicitly in the message - such as a key handle, a user ID, a client IP address, or an RP IP address - in combination with relevant information stored in data storage 35 (Fig. 1). For example, given a key handle, the authenticating server may look up the key and the user with which the key handle is associated in the data storage. (It is noted that in the context of the present application, including the claims “looking up” or“identifying” a user may include looking up or identifying any identifier for the user or for a device belonging to the user, even without identifying the name of the user.)

Subsequently to identifying the key, the authenticating server may generate a response 56 to the challenge by using the key to sign the challenge, even without first requiring that user 26 authenticate himself. The authenticating server may then cause the response to be communicated to the RP. For example, the authenticating server may pass the response to the client such that the client passes the response to the RP. (As a specific example, the authenticating server may pass the response to the aforementioned software agent, and the software agent may then pass the response to the application that submitted the request to authenticate, thus causing the response to be passed to the RP.) Alternatively, the authenticating server may pass tire response directly to the RP.

Alternatively, subsequently to identifying the user to whom the key is assigned, the authenticating server may request, from user 26, proof 54 of possession of at least one authentication factor (AF) associated with the user to whom the key is assigned, as described above with reference to Fig. 1. In other words, the authenticating server may request that user 26 prove that he is the user to whom tire key is assigned. (In such cases, the authenticating server may not identify the key until after proof 54 is recei ved.)

Subsequently, in response to the user proving possession of the authentication factor, the authenticating server generates response 56 and then causes the response to be communicated to the RP, e.g., by communicating the response to the client such that the client communicates the response to the RP. On the other hand, if the requested proof is not recei ved within a predefined time limit, the authenticating server refrains from signing the challenge. In such a case, the authenticating server may return a faulty response to the client, such that the client cannot authenticate to the RP. Alternatively, the authenticating server may send the client an error or close the connection wdth the client, thus causing the client to close the connection between the client and the RP.

Typically, the authenticating server implements adaptive authentication, based on authentication policies stored in data storage 35 (Fig. 1). In other words, the authenticating server decides whether to request proof 54 from the user based on relevant parameters of the client’s request to authenticate to the RP and, optionally, a stored record of previous authentication requests and/or other data collected by security systems or sensors. Examples of relevant parameters include the user ID that was used to generate tire request to authenticate, the identity of the RP, the identity of the client, and the time of the request. In some embodiments, the authenticating server computes a measure of risk associated with each request to authenticate to the RP, and then requests proof 54 in response to the measure exceeding a predefined threshold.

Thus, for example, in response to the aforementioned historical record including a relati vely large number of requests (“large” being quantified by the relevant authentication policy) generated under the user ID and directed to RP 44, the authenticating server may sign the challenge without first requesting proof 54 from the user. On the other hand, if the record includes fewer such requests, the authenticating server may require that the user first submit proof 54. (In some cases, the authenticating server may decide, based on the aforementioned relevant parameters, not to sign the challenge regardless of whether the user possesses the authentication factor.)

In some embodiments, the authenticating server requests proof 54 directly from the user. In other embodiments, as shown in Fig. 2, the request for the proof of possession is performed via an MFA provider 46. In particular, the authenticating server communicates, to MFA provider 46, a request 52 to authenticate the user (For simplicity, the message in which request 52 is contained, along with the subsequent messages in the flow of communication, are not explicitly labeled in Fig. 2 or mentioned in the present description. ) In response to receiving request 52, the MFA provider communicates, to user 26, a request 53 to provide proof of possession of the authentication factor. Subsequently, the user may communicate the proof to the MFA provider. In response to receiving the proof, the MFA provider may authenticate the user and then communicate an authentication confirmation 55 to the authenticating server. Alternatively, the MFA provider may forward the proof to the authenticating server and the authenticating server may then authenticate the user.

In some embodiments, the required authentication factor includes a cellphone, such as a smartphone. For example, the authenticating server may identify an identifier of the cellphone of the user to whom the key is assigned. Subsequently, the authenticating server may pass the identifier, along with request 52, to the MFA provider. In response to receiving the identifier and the request, the MFA provider may communicate a message to the cellphone, the message asking the user of the cellphone to confirm that he requested to authenticate to the RP. Subsequently, provided that user 26 is carrying the cellphone, the user may provide the confirmation, thus proving possession of the cellphone.

In general, the identifier communicated to the MFA provider may include any suitable alphanumeric string, such as a phone number, an IP address, or a dedicated identifier used by the authenticating server and the MFA provider. In some embodiments, tire MFA provider includes a push-notification service, and the message sent to the user includes an IP-based push notification.

Alternatively or additionally, request 53 may be communicated to client 22. For example, the MFA provider may communicate (e.g., via short message service (SMS)) a one-time password (OTP) to the cellphone and also communicate request 53 to client 22, requesting that user 26 prove possession of the cellphone by submitting the OTP. Alternatively, request 53 communicated to client 22 may request that user 26 submit (and hence prove possession of) another, predesignated password, which functions as the required authentication factor.

It is noted that the authenticating server is also configured to perform, in lieu of the regular token, any other relevant functions required by the protocol. For example, in response to receiving (or signing) the challenge, the authenticating server may increment a counter that tracks, for each key, the number of requests (or the number of successful requests) to authenticate. The authenticating server may then generate the response by signing the counter value in combination with the challenge. Alternatively or additionally, the authenticating server may sign, in combination with the challenge, the aforementioned URI, TLS Channel ID, and/or application ID.

AUTHENTICATING TO THE RP USING THE PROXY SERVER

Reference is now made to Fig. 3, which is a schematic illustration of a flow of communication for authenticating to RP 44 using proxy server 24, in accordance with some embodiments of the present invention.

In some embodiments, proxy server 24 proxies between the client and the RP. Thus, the client communicates request 48 to the RP via proxy server 24. In response to receiving request 48, the RP generates challenge 50, which is directed to the client, and passes the challenge to the proxy server in challenge-containing message 49. In response to receiving the challenge, the proxy server causes request 45 to be passed to the authenticating server.

For example, as described above with reference to Fig. 2, challenge-containing message 49 may contain code that, if executed by the client, would cause the client to pass request 45 to the token required by the protocol. In such a case, the proxy server may modify the code to cause the client to pass request 45 to the proxy server upon execution of the code by the client. The proxy server may then pass the modified code, together with the challenge, to the client, in a modified challenge-containing message 49’. Subsequently, upon execution of the modified code by the client, the proxy server may receive request 45 from the client. In response to receiving request 45 from the client, the proxy server may pass request 45 to the authenticating server. Alternatively, the proxy server may modify the code to cause tire client to pass request 45 directly to the authenticating server. Subsequently, upon execution of the modified code by the client, the authenticating server may receive request 45 from the client.

In some cases, as described above, the aforementioned code includes a call to an API. In such cases, the proxy server may modify the code to call a different API, such that, upon execution of the modified code, the client passes request 45 to the proxy server or directly to the authenticating server. As a specific example, for the U2F protocol, the code may include a call to a javascript function named“u2f.sign,” which, when executed, causes the challenge to be sent to a physical U2F token in such a case, the proxy server may replace the call to“u2f.sign” with a call to another javascript function that, when executed by the client, causes the client to pass request 45 to the proxy server or directly to the authenticating server.

As yet another alternative, in response to receiving the challenge, the proxy server may generate request 45 on behalf of the client and then pass request 45 directly to the authenticating server. An advantage of such embodiments is that the client need not support the authentication protocol used by the RP.

In response to receiving request 45, the authenticating server may request, e.g., via MFA provider 46, proof of possession of at least one authentication factor from the user, as described above with reference to Fig. 2. Subsequently, in response to receiving the proof or confirmation from the MFA provider that the proof was received, the authenticating server may generate response 56 and then pass the response to the proxy server.

In response to receiving the response, the proxy server causes the response to be passed to the RP. For example, as shown in Fig. 3, the proxy server may forward the response to the client such that the client then passes the response to the RP via the proxy server. Alternatively, the proxy may forward the response directly to the RP.

Alternatively, for embodiments in which request 45 is passed directly from the client to the authenticating server, the authenticating server may pass response 56 directly to the client. The client may then pass the response to the RP via the proxy server.

As yet another alternative, as described above with reference to Fig. 2, the authenticating server may pass the response directly to the RP.

As described above with reference to Fig. 1, the functionality of both the authenticating server and the proxy server may be performed by a single server. In other words, the authenticating server may receive the challenge from the RP by proxying between the client and the RP. In response to receiving the challenge, the authenticating server may pass the challenge to the client, and then receive request 45 from the client. Subsequently, following authentication of the user, the authenticating server may generate the response and then pass the response to the client. Finally, the client may pass the response to the RP via the authenticating server. Alternatively, the authenticating server may pass the response directly to the RP.

The scope of the present invention includes any suitable technique for ensuring that communication between the client and the RP passes through the proxy server. For example, the proxy may serve as a gateway for access to network 30 (Fig. 1) from the LAN or cloud computing environment to which client 22 belongs. Alternatively, the application, such as the web browser, used by the client to request to authenticate to the RP may be configured to communicate with the RP via the proxy. As yet another alternative, the client may be configured to use the proxy server for all outgoing connections to network 30 or for all outgoing Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) traffic. The proxy server typically uses a certificate signed by a certificate authority trusted by the client, such that the proxy server may decrypt the traffic received from the client.

EXAMPLE ALGORITHMS

Reference is now made to Fig 4, which is a schematic illustration of an example algorithm 58 for authenticating to RP 44 (Fig. 1), in accordance with some embodiments of the present invention. Algorithm 58 is executed by client 22 (Fig. 1).

Algorithm 58 begins with an authentication-requesting step 60, at which the client requests to authenticate to the RP. Subsequently, at a challenge-receiving step 62, the client receives a challenge from the RP. In response thereto, the client, at a request-communicating step 64, communicates a request to sign the challenge to the authenticating server. Subsequently (provided the user is authenticated by the authenticating server), the client receives a response to the challenge at a first response-receiving step 66. Finally, the client communicates the response to the RP at a response-communicating step 68.

Reference is now made to Fig. 5, which is a schematic illustration of an example algorithm 90, executed by the authenticating server, for facilitating authentication to the RP, in accordance with some embodiments of the present invention.

Algorithm 90 begins with a first request-receiving step 92, at which the authenticating server receives, from the client, a request to sign a challenge. In response to receiving the request, the authenticating server decides, at a deciding step 94, whether authentication of the user is required. If not, the authenticating server generates a response to the challenge at a response- generating step 100, by using the appropriate key to sign the challenge. Subsequently, at a first response-passing step 102, the authenticating server causes the response to be passed to the RP, e.g., by passing the response to the client such that the client passes the response to the RP.

On the other hand, if authentication is required, the authenticating server requests, at a proof -requesting step 96, that the user prove possession of at least one authentication factor. (This request may be performed using a third-party MFA provider, as described above with reference to Figs. 2-3.) Subsequently, at a checking step 98, the authenticating server checks whether the user proved possession of the authentication factor within a predefined period of time if yes, the authenticating server performs response-generating step 100 and first response-passing step 102, as described above. Otherwise, the authenticating server closes the connection with the client at a connection-closing step 104, or otherwise inhibits the client from authenticating to the RP.

As described above with reference to Fig. 3, the various communication steps belonging to algorithm 58 and algorithm 90 may be performed via proxy server 24 (Fig. 1). In this regard, reference is now made to Fig. 6, which is a schematic illustration of an example algorithm 70 for proxying between the client, the authenticating server, and the RP, in accordance with some embodiments of the present invention.

Algorithm 70 begins with a second request-receiving step 72, at which the proxy server receives a request to authenticate to the RP from the client. In response to receiving the request, the proxy server passes tire request, at a first request-passing step 74, to the RP. Subsequently, at a challenge-and-code-receiving step 76, the proxy server receives a challenge with relevant code from the RP Next, the proxy server modifies the code at a code -modifying step 78, and then passes the challenge with the modified code to the client at a challenge-passing step 80.

Subsequently, at a third request-receiving step 82, following execution of the modified code by the client, the proxy server receives, from the client, a request to sign the challenge. In response to receiving the request, the proxy server passes the request to the authenticating server at a second request-passing step 84. Subsequently, (provided the user is authenticated by the authenticating server), the proxy server receives a response to the challenge at a second response- receiving step 86. Finally, at a second response-passing step 88, the proxy server causes the response to be passed to the RP, e.g., by passing the response to the client such that the client passes the response, via the proxy server, to the RP.

It will he appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof that are not in the prior art, which would occur to persons skilled in the art upon reading the foregoing description.