Risk-Based Factor Selection

The present technology provides for altering an authentication technique in response to a detection of a possible attack to which the authentication technique is vulnerable. An authentication provider can receive an authentication request to authenticate to a first resource, where the authentication to the first resource is permitted using a particular authentication technique, includes contextual information associated with the first access device and information identifying the first resource. Based on the contextual information, the authentication provider can determine that the authentication request is subject to an ongoing attack, and determine, an alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique. The authentication provider can require the first user account to authenticate with the first resource using the alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique.

TECHNICAL FIELD

The present disclosure relates to multi-factor authentication. Aspects of the disclosure involve identifying risks related to multi-factor authentication and adjusting available authentication methods to mitigate the identified risk.

BACKGROUND

Two-factor authentication (2FA) is a simple, effective way to make sure users are who they say they are. Two-factor authentication is important to network security because it mitigates the risks associated with compromised passwords. If a password is hacked, guessed, or phished, it is no longer enough to give an intruder access because without approval at the second factor, a password alone may not be useful. However, 2FA is not impervious to nefarious attempts that try to circumvent the second factor authentication methods.

DETAILED DESCRIPTION

Certain aspects of this disclosure are provided below. Some of these aspects may be applied independently and some of them may be applied in combination as would be apparent to those of skill in the art. In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of aspects of the application. However, it will be apparent that various aspects may be practiced without these specific details. The figures and description are not intended to be restrictive.

Overview

The present technology provides for altering an authentication technique in response to a detection of a possible attack to which the authentication technique is vulnerable. An authentication provider can receive an authentication request to authenticate to a first resource, where the authentication to the first resource is permitted using a particular authentication technique, including contextual information associated with the first access device and information identifying the first resource. Based on the contextual information, the authentication provider can determine that the authentication request is subject to an ongoing attack, and determine, an alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique. The authentication provider can require the first user account to authenticate with the first resource using the alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique.

The authentication service is a multi-factor authentication service and the particular authentication technique and the alternative authentication technique are multi-factor authentication techniques.

The present technology further includes presenting a user interface for a primary authentication technique to authenticate the first user account with the first resource, and after successful completion of the primary authentication technique, sending the authentication request to the authentication service, where the contextual information associated with the first access device includes one or more of data identifying a network from which the access device is connected, the IP address of the access device, a browser version used to access the first resource, an identification of browser extensions installed in the browser used to access the first resource, an operating system on the access device, and a type of access device. The authentication service can determine, based on the contextual information and the information identifying the first resource, that the particular authentication technique is permitted by a policy associated with the first resource. The authentication service can provide the particular authentication technique to the first user account, and determine that the first user account failed the particular authentication technique.

The present technology further includes setting a period in which the authentication provider will require the user account to authenticate with the first resource using the alternative authentication technique before allowing the user account to authenticate with the particular authentication technique.

In some embodiments, the first resource is associated with an access policy configured at the authentication service. The access policy specifies a rule for determining that the authentication request is subject to an ongoing attack.

In some embodiments, the service determines the characteristics associated with at least one attack are below individualized thresholds configured by the service. For example, the service might not determine an attack is occurring if a service utilizes a VPN for access devices, where the same user account may routinely attempt to authenticate from different IP addresses.

In some embodiments, the alternative authentication technique includes a multi-device push, where the multi-device push includes sending an access code to the access device for entry into the authentication device, and receiving the access code from the authentication device.

The present technology further includes prior to providing the particular authentication technique, offering options for at least two authentication techniques, where the user account selects the particular authentication technique.

In some embodiments, the present technology the determination that the first user account failed the particular authentication technique can occur prior to the determining that the authentication request is subject to an ongoing attack.

The present technology also includes an attack mitigation requirement. The attack mitigation requirement defining when the alternative authentication technique should be applied to the user account and when the alternative authentication technique should be applied to all requests for authentication to the first resource.

Detailed Description of Example Embodiments

Disclosed herein are systems and methods for identifying attacks associated with attempts to thwart multi-factor authentication (MFA) and providing alternatives to continue authentication that mitigates or removes the risk associated with the attack. The risk-based factor selection systems and methods disclosed herein use signals (e.g., a number of requests sent for authentication exceeding a threshold) from authentication attempts to determine, in real-time or close to real-time, whether the user is experiencing a certain type of attack. If so, the system may restrict the available authentication factors to only those that are known to be more secure against that specific attack.

In multi-factor authentication, when a user performs second factor authentication through a service, such as DUO or OKTA, they are often presented with a number of possible factors that they can use to authenticate their identity. These factors may include hash-based one-time password (HOTP) codes, phone calls, a push to a mobile application, web-based authentication (e.g., WebAuthN), etc. For example, a push to a mobile application, such as a push to Duo Mobile, typically includes the following steps: (1) a server receives a pre-authorization request (e.g., a user entered a password correctly, and now the server is being requested to send an MFA push); (2) the server cross-checks information to make a determination on whether the characteristics associated with the user comply with a policy (e.g., a company user policy) which allows the user to access the requested service. Such cross-checked information may include information associated with the user's IP address (e.g., their location or other geographical information), whether or not the user is on a permitted network (e.g., their home private network), browser information (e.g., browser version, what extensions are installed, etc.), the operating system (OS) type, type of computer, a unique ID of an application being accessed, the company, time of day), etc. Based on these types of information, the server decides whether the user is compliant with the policy, and then; (3) the server provides the MFA push to the user, for example, by sending to a known device registered with the user, a request for the user to acknowledge the sign-in request. This acknowledgment may be in the form of two confirmation buttons, one approving the request and one disapproving the request. It should be noted that the type of MFA provided to the user may be user selected or may be based on the policy associated with the company, service, user, other methods, or any combination thereof. If the user selects the “approve” button, the device originally seeking the connection permission is allowed to connect to the respective service.

Some of the MFA factors are more susceptible to certain attacks than others. For example, a push style authentication factor may be compromised by a “push harassment” style of attack, among others. A push harassment attack occurs when a bad actor sends pushes repeatedly to a single user, hoping to annoy them into finally approving the push. The user is inundated with push requests and may even accidentally approve the request, granting the bad actor access to the service.

To prevent a push harassment attack or other style of attack from the bad actor, the server utilizes user information (e.g., IP addresses) to identify the respective locations of the access device and the authentication device. For example, if the access device and the authentication device are in two different countries, the server can detect a potential attack and limit the affected users' factors to only non-push or “Verified Push.” Verified push is a higher friction version of a mobile push experience, in which the user presented with a code on the access device and is asked to enter the code on the mobile device in order to approve the push. The code (e.g., a six-digit code) may be shown to the user in a prompt on the user's laptop when the push is initiated (or shortly thereafter). The code then must be entered along with the push approval on the authentication device, such as the user's mobile device. In this regard, the user cannot approve the push unless they are the one who triggered it, whereby the trigger came from the user's access device, such as the user's laptop, and the code is then displayed on the user's laptop with approval and entry of the code being on the user's authentication device separate from the work device.FIGS.3A-Billustrates an example screen of the information displayed on the access device (shown inFIG.3A) and the authorization device (shown inFIG.3B).For example, if the system identifies (through IP address or other means) that the access device is in the United States and the authentication device is in the United Kingdom, the system may limit (e.g., based on a pre-determined policy) the affected users' factors to only non-push or Verified Push factors.

Another example of an attack that may exploit certain MFA factors is a “push spray” attack. A push spray attack occurs when a bad actor sends push authentications to many users, hoping that some of them will accept the fraudulent push. Bad actors targeting specific services may obtain large amounts of data from a data breach, including user information such as usernames and passwords. These data breaches, which are becoming increasingly prevalent, help facilitate these types of attacks. However, as previously discussed, usernames and passwords account for only one factor in multi-factor authentication. The bad actors utilize the push spray to send push authorization requests to the users identified by the data breach hoping at least one user will accept the request that allows the bad actors into the service. When the push spray attack is detected (e.g., by monitoring the number of push requests generated from a single source), the server may limit the affected users' factors to only non-push or Verified Push.

Yet another example of an attack that may exploit certain MFA factors is “Passcode Phishing” (also known as adversary-in-the-middle). Passcode phishing may occur when a bad actor sets up a fake site (e.g., a web portal mimicking the look of a real service portal site) that looks like a legitimate passcode prompt to collect passcodes from users and reuse them to gain fraudulent access. The attacker sends a user through a proxy and retrieves credentials and/or session tokens by manipulating the end user into thinking they are authenticating into a legitimate resource or application. Attackers often pose as people or organizations a user may have interacted with or that sound official, such as businesses, government organizations, and trusted service providers. These attacks are not necessarily new, but hacking tools/scripts are constantly evolving and have made it easier for attackers to execute them. Although identified methods of passcode phishing are discussed above, it should be noted that bad actors may use other methods, such as malware, virus software, ransom software, social engineering (e.g., fraudulent emails requesting information from the user or requesting password resets), combinations of the same, etc., to obtain user information in a phishing attack.

Though other types of attacks are possible, push spray, push harassment, adversary-in-the-middle, and passcode phishing attacks are common types of attacks, all of which are made more susceptible by “push fatigue.” This may occur because the user is distracted or overwhelmed by constant notifications, and it may be misinterpreted as a bug or confused with other legitimate authentication requests. Repeated multi-factor authentication requests result in users paying less attention to the details of their login, causing a user to mindlessly accept a push login or pay less attention to the site they are logging into, which may be fraudulent but look very similar to the legitimate site. These attacks are all particularly effective-not because of the technology involved, but because they target the human factor via social engineering.

Identifying when these types of attacks are occurring is the first step in addressing or mitigating these attacks in order to provide heightened security to businesses looking for more security surrounding their systems. Real-time or close to real-time identification of when these types of attacks are occurring may help minimize the risks associated with the attacks. For many types of attacks, statistics, monitoring, and tracking may be used to determine or identify when the attack may be occurring. For example, in a push harassment type of attack, a single IP address associated with a bad actor may be identified as the origin IP for many authentication message requests sent to an end-user. When the system detects a certain number of requests sent from the IP address, that number may exceed a preset threshold and may signal to the system that the attack is occurring. In another example, the system may identify that an

IP address not associated with a known trusted IP address is sending many requests for authentication to the end user. This unknown or untrusted IP address, coupled with the threshold for a number of requests sent being exceeded, may also be a signal to cause the system to identify that the push harassment type of attack is occurring. In yet another example signaling to the system that a push harassment type of attack is occurring, the system may identify that a single user is being sent requests for authentication originating from multiple IP addresses, and the number of requests exceeds a threshold associated with a policy set at the server. In this regard, identification of a push harassment type of attack may be associated with a request threshold, a user, and/or an IP address wherein the system identifies that the attack is occurring based on the threshold, the user, and/or the IP address(es) associated with the requests.

In another example, a push harassment type of attack may be identified as occurring based on a number of rejected requests for authorization received at the server from an end-user. A bad actor may be sending request after request for authorization in hopes that the end-user (i.e., a trusted user associated with the right of access) may accidentally or, possibly out of frustration, accept one of the many requests sent. The end-user may reject a certain number of requests, and that number may exceed a threshold that signals to the system an attack may be occurring. In another example, the system may determine an attack is occurring based on a number of requests for authorization exceeding a threshold and the time of day. For example, a number of requests may be sent in the middle of the night by a bad actor to harass the end-user during a time when the end-user may be sleeping or otherwise not usually working in an effort to get the end-user to accept one of the requests, possibly out of frustration or confusion.

Based on the time of day and the number of attacks, the system may determine that the end-user is under attack. In this regard, the system may combine other signals (e.g., time of day, unknown/untrusted IP addresses, unknown/untrusted devices, requests over a set period of time, number of rejected requests, etc.) with a threshold to identify that an attack is occurring and take steps to mitigate or address the attack.

Similar to the methods for determining a push harassment type of attack, in another example, the system may identify a push spray attack when a threshold for request authorizations is exceeded. The system may detect that a single IP address is sending requests to a number of end-users/devices associated with a particular service and the number may exceed a predefined threshold, signaling to the system that an attack is occurring. In some examples, the system may determine that a number of requests for authorization are being sent to multiple end-users of a service and that the IP address is not part of a pre-approved list of IP addresses known/trusted to send the requests. In this regard, the system may use cross-reference a list or policy to help determine whether an attack may be occurring. The system may identify that a push spray attack is occurring based on the unknown/untrusted source coupled with a number of requests exceeding a threshold. A push spray attack may be misidentified in cases where a service or company utilizes a VPN which creates the impression that a single IP address is requesting a number of authorizations wherein the number exceeds a threshold. In this case, the system may utilize the list of approved IP addresses as a tool correctly identify that the requests may be legitimate. In another example, the threshold may be adjusted (e.g., by a system administrator for the service/company) by a policy or user to allow a certain number of requests (e.g., based on a number of known end-users scheduled to work at that time) or may disable the threshold signal for that service during a period of time.

An adversary-in-the-middle or a passcode phishing attack may be identified as occurring by the system based on the IP address associated with the request or may be identified based on software (e.g., an endpoint agent on the end-user's computing device) that identifies the IP of the end-user. For example, a bad actor may set up a portal, such as a web portal, that mimics a genuine portal an end-user may utilize to sign into a service (e.g., “du0.com” with a zero instead of “duo.com” with an “o”). A user may not notice the slight difference in web addresses after accidentally typing “du0.com” which may easily occur due to the proximity of the zero key on the keyboard as compared to the “o” key. In this example, the adversary-in-the-middle may intercept the user's login password and username, communicate the information to the actual server, and relay the response to the end-user without the end-user noticing that the portal is not authentic. The bad actor may then use the phished information to request a multi-factor authentication and login as the end-user after the end-user approves the request for authentication based on their own attempt (albeit at an erroneous portal) to login. In this regard, the adversary-in-the-middle intercepts the end-user's information and uses the information along with the fact that the user is simultaneously trying to log in to trick the user into approving a request for authentication, thereby gaining unauthorized access to the service. The system may identify that the request for authorization is coming from an unknown/untrusted portal (e.g., based on the web address of the portal not being associated with a known/trusted source) and take steps to mitigate the attack. In another example, the software (e.g., the endpoint agent) may identify and notify the system that the request for authorization is coming from a suspicious source by comparing the IP address associated with the end-user to the IP address of the request's source and determining they are not the same. In another example, the software may use other information (e.g., browser information, operating system information, location, packet timing, etc.) to identify that the end-user did not make the request for authentication. In this regard, the identification of an adversary-in-the-middle or passcode phishing attack is occurring may be based on packet timing information. For example, the request for authentication may take a certain number of hops or a certain amount of time to reach the system whereas a pre-authorization may take a different amount of time to reach the system, and based on a threshold, the system may determine that the packet timing for each is too different which may signal an attack. Once the system has identified that a certain type of attack is occurring, the system can determine (e.g., based on the type of attack detected or information associated with the attack) alternate authentication factors an end-user may utilize that are less susceptible to the identified attack. In some examples, the system may present the user with a specific alternate method or factor for authentication. In other examples, the system may determine that several alternate factors are less susceptible to the type of attack occurring and may present a choice (e.g., via a pop-up message, email, or other notification) to the end-user to choose the alternate 2FA or MFA factor. For example, if the system identifies that a push spray attack may be occurring, the system may limit (e.g., based on a pre-determined policy) the affected users' factors to only non-push or Verified Push factors. In this regard, the user may have to authenticate using non-push methods (e.g., WebAuthN, YubiKey, biometrics, passcodes, HOTP codes, tokens, SMS codes, hardware dongle, etc.) that are less susceptible to push spray attacks. In another example, if the system identifies that a push harassment type of attack may be occurring, the system may disallow push factors or may switch to a “pushless push” (e.g., use the end-user's mobile device to authenticate but not trigger a push notification for it). In another example, if the system identifies a passcode phishing or adversary-in-the-middle attack, the system may temporarily block the passcode as an available authentication factor. With any type of attack having been identified, the system may determine that a threshold update is required. In this regard, the system may adjust the thresholds or may prompt a company/service administrator to update the thresholds based on any number of metrics including frequency of attacks, number of falsely identified attacks, time periods, etc. It should be noted that the system may use artificial intelligence (AI) software to track and determine thresholds in various possible examples.

In some examples, the list of alternate, less susceptible factors may be determined by a rule or policy associated with the type of attack, company, and/or the type of service. In other examples, a company/service administrator may decide on acceptable alternate, less susceptible methods for the end-user to continue authentication. In this regard, the alternate, less susceptible factors may be configurable and may be specific to each company/service. In one example, the alternate, less susceptible factors may be end-user specific or may pertain to certain groups of end-users.

In some examples, after the system has determined that a specific type of attack is or is potentially occurring, and after the system adjusts the allowed MFA factors to those less susceptible to that type of attack and the end-user successfully authenticates using one of the identified less susceptible factors, the system may allow all previous MFA factors for that company/service. In some examples, the system may determine (e.g., based on a previous successful authentication) that all previously allowed MFA factors are acceptable authentication factors. In some examples, after a period of time (e.g., a predetermined timeout period) the system may determine that or may determine that only certain previously allowed factors are acceptable authentication factors. In this regard, the system may track unsuccessful attempts and successful attempts, may track time periods between attempts, and may base the list of allowed MFA factors on the number of failed or successful attempts and/or a time associated with the attempts in various possible examples. It should be noted that the system may also determine the allowed list of MFA factors based on a rule or policy, configurable rule or policy, feedback from a company/service, etc., and combinations of the same in various possible examples.

FIG.1illustrates an example environment utilizing a multi-factor authentication (MFA) system in accordance with some aspects of the present technology. User102can gain authorized access to resource110by using authentication device104. User102can be any user including an employee, contractor, client, member of an organization, or private individual, etc. attempting to access a service. The authentication device104can be hardware, software-only, or combinations thereof. The authentication device104can be a mobile device or a personal computer.

Resource110can be any service, resource, device, or entity which requires authentication of user102. For example, resource110can be a social media service, bank, hospital, motor vehicle department, bar, voting system, Internet of Things (IOT) device, or access device. In some embodiments, resource110can be accessed by user102through an access device114, such as a mobile phone or personal computer. In some embodiments, resource110can be accessed by user102through an application116on an access device114that is specifically designed for accessing resource110, or through a more general application116that can access multiple services, such as a web browser, or portions of an operating system. In some embodiments, resource110can be a plurality of resources, such as a network or enterprise system.

Resource110can authenticate the identity of user102on its own through the use of an authentication mechanism, and can utilize the authentication service108to provide an additional factor of authentication. For example, user102can attempt to access the resource110using the access device114. In some embodiments, the access device114can also be the authentication device104, such as when user102attempts to access the resource110using an app or browser on authentication device104. The resource110can perform a first authentication mechanism by interacting with the access device114. Thereafter, the resource110can request an additional authentication using authentication device104.

In some embodiments, the additional authentication can include requesting a code generated by the authentication device104. For example, the MFA application106might generate a pseudo-random number using a mechanism agreed upon with resource110. The user102can operate the authentication device104to cause the MFA application106to generate the pseudo-random number, which the user102can then enter into the access device114to achieve the additional authentication. In some embodiments, if the authentication device104is equipped with a trust platform module112, the MFA application106can utilize the trust platform module112to generate the pseudo-random number.

In some embodiments, the additional authentication can include requesting a code or authorization generated by the authentication device104by making the request through the authentication service108. For example, the resource110can pass information identifying the user102to the authentication service108with a request for additional authentication. The authentication service108can send a request (typically a push request) for authentication to the authentication device104, which is known to be a device associated with the user102. The user can respond to the request for authentication on the authentication device104by interacting with the MFA application106to perform the required actions. When the required actions are properly performed, the MFA application106can send a communication informing the authentication service108of the successful authentication, and the authentication service108can inform the resource110of the successful authentication.

In some embodiments, the additional authentication can include requesting a code generated at resource110to be entered at the authentication device104by making the request through the authentication service108. For example, the resource110can pass information identifying the user102to the authentication service108with a request for additional authentication. The authentication service108can send a request (typically a push request) for authentication to the authentication device104, which is known to be a device associated with the user102. In this example, the MFA application106presents a user interface requesting that the user102enter a code that is presented on the access device114that originated from the resource110. The user can respond to the request for authentication on the authentication device104by interacting with the MFA application106to perform the required action by entering the code. When the code is properly entered, the MFA application106can send a communication informing the authentication service108of the code, and the authentication service108can pass the code to the resource110where the resource110will consider the additional authentication successful when the received code matches the code sent to the access device114.

In some embodiments, the authentication device104and/or the access device114can also report context data to the authentication service108. As addressed above the authentication device104can include the MFA application106that can communicate with the authentication service108. The access device114can include a security agent118that can also communicate with the authentication service108. The MFA application106and the security agent118can gather and send information to the authentication service108. For example, the information can include biometric, behavioral, and contextual data from user102. These biometrics can include, for example, fingerprints, facial detection, retinal scans, voice identification, or gait data, among other biometrics. The context data can include a time since the user last interacted with the device, changes to the network connection experienced by the device, information about the integrity of the operating system of the device, information about what operating system and what version of the operating system the device is running, among other examples. This information can be used by the authentication service108to determine if the device should be trusted to be used as part of the authentication process or trusted to access the resource110. In some instances, the information can indicate that something has changed about the user102, the authentication device104, or the access device114during an authenticated session with resource110can take certain actions depending on a configured policy to access the resource110.

FIGS.2A-Billustrates an example method200for risk-based factor selection wherein the method includes various aspects of the disclosure as they relate to receiving a pre-authorization, identifying a certain type of attack, adjusting available MFA factors, presenting the factors to the user, and allowing or denying authorization. Although the example method200depicts a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence that does not materially affect the function of the method200. In other examples, different components of an example device or system that implements the method200may perform functions at substantially the same time or in a specific sequence.

According to some examples, the method includes presenting a user interface for a primary authentication technique to authenticate the first user account with the resource at block205. For example, the access device114, illustrated inFIG.1, may present a user interface for a primary authentication technique to authenticate the first user account with the resource (i.e, resource110), such as through an application installed on the user's102laptop (i.e., access device114). As previously discussed, access device114may include hardware (e.g., a computer), software (e.g., a browser extension), a website (e.g., a web portal) hosted on a separate computing device, or any other application of the device capable of presenting the interface for a primary authentication technique. In some examples, the primary authentication technique is a username and password. In some examples, the primary authentication technique may be any authentication technique capable of verifying the user's102information.

It should be noted that presenting a user interface for a primary authentication technique may have been initiated by a bad actor as part of an initial step in gaining access to a resource110.

In some examples, a legitimate user102may have requested the primary authentication technique while a bad actor is inconspicuously monitoring the legitimate user, such as in an adversary-in-the-middle attack. In this regard, the primary authentication technique may be presented based on a legitimate request, an illegitimate request, or simultaneous legitimate and illegitimate requests.

According to some examples, the method includes sending the authentication request to the authentication service at block210. For example, the resource110may send the authentication request to the authentication service108. In some examples, the authentication service is a multi-factor authentication service. In some examples, the authentication service is a two-factor authentication service. In this regard, the authentication service may require one or more factors to authenticate the user in various possible examples. In some examples, the authentication request includes contextual information associated with the access device114of the request and information identifying the resource110. The authentication request may include contextual information associated with the request and/or the user102including the IP address of the access device, a browser version, an identification of browser extensions, an operating system on the access device, a type of access device, time of day, geographical information, combinations of the same, etc., in various possible examples. In some examples, the contextual information associated with the access device114, authentication device104, and/or user102includes one or more of data identifying a network from which the access device or authentication device is connected. In some examples, the request or contextual information includes information about the user, such as a name or username, password, user ID, combinations of the same, etc., in various possible examples.

According to some examples, the method200includes determining, by the authentication service and/or authentication device, based on the contextual information and the information identifying the resource that the particular authentication technique is permitted by a policy associated with the resource at block215. For example, the authentication service108illustrated inFIG.1may determine, based on the contextual information and the information identifying the resource110, that the particular authentication technique is permitted by a policy associated with the resource110. In some examples, the authentication service108may set the policy associated with the resource110. In some examples, the policy may be set by the resource110. In some examples, the policy may be set by an administrator or user of the resource110. It should be noted that the policy associated with the particular authentication technique may be updated, adjusted, changed, or otherwise set for each user102or user account, groups of users or accounts, resource110, particular authentication technique, authentication device104, authentication session, combinations of the same, etc., in various possible examples.

Further, the method200may determine that the contextual information, such as from the access device, is only allowed to utilize a subset of available authentication techniques (e.g., two of five available authentication techniques) associated with the resource, authentication service, and/or policy. For example, the contextual information may include information that the user102is on a public network (e.g., accessing the internet on a laptop in a coffee shop), and the authentication provider108may determine (e.g., based on the policy and the contextual information) that the user102may only utilize a push type authentication method, biometric authentication method, or Verified Push type authentication method. In this regard, the authentication provider108and/or authentication device104may consider contextual information associated with the request and/or the user102to indicate a higher risk associated with allowing the user to use particular authentication techniques.

According to some examples, the method includes providing the particular authentication technique to the first user account at block220. For example, the authentication device104may provide the particular authentication technique to the first user account via a website or web portal, application, email, pop-up extension, notification (e.g., email), computing device, hardware device (e.g., a fingerprint reader), combinations of the same, etc., in various possible examples. In some examples, the authentication service108or the resource110may provide the particular authentication technique to the user via the authentication device104or the access device114.

In some examples, the user102may be offered options for at least two authentication techniques. For example, authentication provider108or authentication device104may offer the user the option to select between a “push” (e.g., a pop-up on the user's mobile device, or access device) or a one-time passcode (OTP) (e.g., sent via email to the user account associated with the access request). In some examples, the options associated with the available authentication techniques may be based on the policy associated with the resource110or authentication service108. In some examples, the options associated with the available authentication techniques may be based on the user account, type of device requesting the access, contextual information associated with the request, data including previous requests or other historical information, a current network or threat level assessment, geographical information, combinations of the same, etc., in various possible examples. In some examples, the user associated with the user account selects the particular authentication technique.

According to some examples, the method includes determining that the first user account failed the particular authentication technique at block225. For example, the authentication device104or the authentication service108may determine that the first user account failed the particular authentication technique. In some examples, determining that the user account failed may be based on a received “deny” indication, such as a response to a push authentication request presented on the authentication device104. In some examples, determining that the user account failed the particular authentication technique includes, the identification of an invalid password, invalid passcode, invalid biometric indicator, invalid hash, invalid decryption, combinations of the same, etc., in various possible examples. In this regard, determining the user account failed the particular authentication technique may be determined by the authentication device104, authentication service108, resource110, combinations of the same, or other trusted sources in various possible examples.

According to some examples, the method includes receiving an authentication request to authenticate to a resource, at block230. For example, a bad actor using an ill gotten (e.g., obtained from malware, purchased on a black market, intercepted from a message, etc.) primary authentication technique (e.g., a genuine username and password) associated with a legitimate user account may initiate an authentication request to authenticate to a resource in hopes that the legitimate user will approve the request once it is generated from the authentication service108, authentication device104, and/or the resource110thereby allowing the bad actor access to the resource110. In some examples, the bad actor may initiate one or more requests. In some examples, the bad actor may initiate many requests for authentication to the resource (e.g., a push spray attack) at the same time, or may initiate the requests one after another over a period of time (e.g., a push harassment attack). In some examples, a legitimate user102may have requested the primary authentication technique while a bad actor is inconspicuously monitoring the legitimate user, such as in an adversary-in-the-middle attack or a passcode phishing attack. In some examples, the bad actor and the user102may have initiated the request to authenticate to a resource at the same time or within a short period of time (e.g., within10minutes of each other). In this regard, the received request to authenticate to a resource may be a legitimate request or may be an illegitimate request.

According to some examples, the method includes determining that the authentication request is subject to an ongoing attack at block235. For example, the authentication device104, trusted provider108, and/or resource110may determine that the authentication request is subject to an ongoing attack. The determination may be based on an identification that the request is originating from a source IP or device not associated with the user102. The determination may also be based on the location of the source IP or device. In some examples, the determination may be based on information tracked over a period of time, such as a number of received authentication requests over a period of time (e.g., 20 requests in 5 minutes) or at a specific time (e.g., requests made in the middle of the night). The tracked information, such as the number of requests, may exceed a preset threshold (e.g., a preset threshold set by a policy, an administrator, the resource, the authentication service, etc.). In this regard, the threshold used in determining that the authentication request is subject to an ongoing attack may be changed or adjusted based on the user102, user group, service, policy or rule, access device, combinations of the same, etc., in various possible examples. The time-out of the push requests indicates a push fatigue attack. In some examples, the authentication service108may determine that the user account is under attack when greater than a threshold number of push requests sent by the authentication service have timed-out. In some examples, the time-out of the push requests may indicate a push fatigue attack or a push harassment attack. The authentication service108may determine that the user account is under attack when greater than a threshold number of requests sent by the authentication service108have been declined by user102which may indicate the attack is a brute force attack. It should be noted that it may be determined the resource is under attack when the threshold is exceeded by a metric associated with the request, user, service, combinations of the same, etc., in various possible examples. In some examples, a number of authentication requests received by the authentication service108that originate from an IP address but are requested on behalf of different user accounts may indicate that a certain type of attack is occurring. In some examples, the authentication request received by the authentication service108originates in a country that differs from the location of the authentication device104, indicating a potential attack from a bad actor. In some examples, a rule or policy may define that the user account may be under attack when the user account is attempting to authenticate from an IP address not previously associated with the user account. In some examples, the authentication service108may see the characteristics associated with some attacks as normal, below an individualized threshold, such as if the provider/service (e.g., resource110) utilizes a VPN for access devices. The user102may routinely attempt to authenticate from different IP addresses within a range of addresses associated with the VPN, and this would be normal i.e., within a threshold configured by the service where the service knows the range of possible addresses. In this regard, the access policy may specify a rule for determining that the authentication request is subject to an ongoing attack in various possible examples. In some examples, the access policy is defined by the resource and may be based on the contextual information. In some examples, determining that the first user102account failed the particular authentication technique occurs prior to the determining that the authentication request is subject to an ongoing attack. It should be noted that user102may determine the authentication request is subject to an ongoing attack in various possible examples. In this regard, the user102may report to the authentication provider108(e.g., via a report malicious activity button, via the authentication device104, or access device, etc.) It should be noted that although specific types of attacks are discussed, any number of attacks, known or unknown, may be detected by the systems and methods disclosed herein in various possible examples.

According to some examples, the method includes determining, an alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique at block240. In some examples, the authentication service108may determine the alternative authentication technique that is less vulnerable to the ongoing attack. In some examples, the authentication device104or resource110may determine an alternative authentication technique that is less vulnerable to the ongoing attack. In some examples, the user102or an administrator may determine the alternative authentication technique. The determination may be based on the contextual information, the user102, user group, the resource110, the access device, a policy or rule, combinations of the same, etc., in various possible examples. In some examples, the determination may be based on the primary authentication technique and the associated contextual information. For example, the primary authentication technique may be a mobile push, such as a push to verify, sent to a mobile device. The bad actor may be initiating repeated requests for the mobile pushes and may be initiating the repeated requests during a time when the user102is sleeping, such as in the middle of the night, during a push harassment attack. In this regard, the bad actor may be trying to get the user102to exhaustedly, or otherwise out of frustration, accept one of the repeated mobile pushes. After the system determines that the primary authentication technique (i.e., the mobile pushes) is subject to the ongoing attack, the system may determine that a Verified Push (described below with respect toFIGS.3A-3B) is less vulnerable to this type of attack because the user102may not simply approve the request via the mobile push. In this regard, the alternative authentication technique may include a multi-device push, a YubiKey, biometric, passcode, HOTP, OTP, phone call, combinations of the same, etc., or an authentication using another trusted service or technique, such a WEBAUTH or WEBAUTHN, in various possible examples. In some examples, the access policy includes an attack mitigation requirement, the attack mitigation requirement defining when the alternative authentication technique should be applied to the user account, group of user accounts, or when the alternative authentication technique should be applied to all requests for authentication to the resource. It should be noted that the systems and methods described herein may be applied to a resource, a second service, multiple services, may be applied to a resource and then changed, combinations of the same, etc., in various possible examples. In this regard, when the alternate authentication technique is applied and/or how often it is applied may be configurable or may be set by the authentication service108.

In some examples, the method includes setting a period in which the authentication provider108will require the user102account to authenticate with the resource, such as resource110, using the alternative authentication technique before allowing the user102account to authenticate with the particular authentication technique at block245. In this regard, the period may be set to mitigate the risk of an ongoing attack thereby reducing the chances that a bad actor gains access to the resource110. In some examples, the period may be set by the authentication service or may be set by the policy associated with the resource. In some examples, the policy may be set by the resource110. In some examples, the policy may be set by an administrator or user of the resource110. It should be noted that the period associated with the particular authentication technique may be updated, adjusted, changed, or otherwise set for each user102or user account, groups of users or accounts, resource110, particular authentication technique, authentication device104, authentication session, combinations of the same, etc., in various possible examples.

Continuing example method200and shown inFIG.2B, the method includes requiring the first user102account to authenticate with the resource, such as resource110, using the alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique at block250. In this regard, the user102may not use any authentication technique available and may only use the alternate technique, or choose between a list of alternate techniques, set by the authentication service108, rule or policy, resource110, administrator, combinations of the same, etc., in various possible examples. Restricting the techniques may help mitigate the risks associated with an ongoing attack while still allowing the user102to be authenticated thereby facilitating the user's102ability to continue working.

According to some examples, the method includes sending an access code to the access device for entry into the authentication device at block255in addition to requiring the first user to authenticate with the resource using the alternate authentication technique like in step250. In some examples, the authentication service108, authentication device104, and/or resource110may require authenticating at least two MFA factors after the user102provides the primary authentication to mitigate the risk associated with the ongoing attack and allow the user102to utilize resource110. In this regard, the method includes receiving the access code from the authentication device at block260for authentication verification at the authentication service108, authentication device104, and/or resource110. Although not shown, method200may repeat any step, combine steps, skip steps, iterate steps, combinations of the same, etc., in various possible examples.

According to some examples, the method includes clearing the period in which the authentication provider108will require the user102account to authenticate with the resource110using the alternative authentication technique after the user account successfully authenticates with the alternative authentication technique at block265. In this regard, once the system determines the risk of an ongoing attack have been mitigated or are otherwise no longer present (e.g., by a successful user MFA authentication), the system may revert back to the default configuration or otherwise allow more or all of the available authentication techniques. In some examples, the authentication service108, authentication device104, and/or resource110may determine when to clear the period. In some examples, a rule or policy associated with the authentication service108, authentication device104, and/or resource110may determine when to clear the period. It should be noted that the period may be configured, such as by a resource administrator or authentication service administrator.

FIGS.3A-Bshow an example of a particular authentication technique including a Verified Push, which may be an alternative authentication technique. It should be noted that the Verified Push may be a primary authentication technique or an alternative authentication technique. Verified Push is a higher friction version of a mobile push, in which the user may be asked to enter a code on an authentication device104or another authentication device, such as a mobile device, in order to approve the push. As shown inFIG.3A, the user102may be presented with a code302, such as a six-digit code. It should be noted that the code302may be any suitable length including numbers, letters, symbols or pictures, and combinations thereof in various possible examples. The code302may be shown in a prompt300, and the prompt may be presented on the user's102access device114, such as a laptop, when the push is initiated (or shortly thereafter). In this regard, the user102may not approve the push unless they are actually the one who triggered it, i.e., the code is on the device that triggered the request. Shown inFIG.3A, the prompt may include a header304indicating what is needed, such as additional verification. Message306may be shown to aid the user102in completing the authentication verification, such as with instructions on how to complete the authentication. In some examples, the user102may be presented with an alternative options button308, which may include alternate authentication techniques available to the user102. It should be noted that the alternate techniques available to the user102through the alternate options button308may be determined by the authentication service108, a rule or policy associated with the resource110, user102, group of users, combinations of the same, etc., in various possible examples. The length of the code may be configurable. For example, more digits may provide a stronger security guarantee because an attacker only has a 1-in-1,000,000 chance of guessing a 6-digit code correctly, versus a 1-in-100 chance with a shorter code, such as a 2-digit code. It should be noted that a Verified Push may be triggered adaptively such as when the user102appears to be involved in a push fraud attack. In this regard, coupling Verified Push with the Risk-Based Factor Selection systems and methods of the present disclosure may help maintain a high security interaction and only be required when it is determined to be necessary, such as by the resource110or authentication service108.

FIG.3Bshows an example verification interface310for inputting the code302that may be presented to the user's102authentication device104, such as a mobile device. The verification interface310may include a header314indicating to the user102what the purpose of the interface may be, such as Verify It's You. The verification interface310may include a message316that aids the user102in completing verification. The code302may be entered into the code verification boxes312. In some examples, the user102may then choose to verify the code by pressing a verify button318. In some examples, the user102may not need to press a verify button318and the code302may automatically be authenticated when entered. In some examples, the user102may choose to deny the authentication by pressing a deny button320. In this regard, the user102may deny the verification because they did not request the code, which may indicate to the authentication service108, resource110, or MFA104that an attack may be occurring.

FIG.4shows an example method400of the particular authentication technique including a Verified Push, which may be an alternative authentication technique. According to some examples, the method includes determining, based on at least one of a type of attack detected and an access policy, an alternate authentication technique at step405. In some examples a Verified Push may be used as the alternative authentication technique if a push spray attack, push fatigue attack, push harassment attack, other types of attacks, combinations of the same, the access device114and authentication device104are located in different countries, etc., is detected. In some examples, the access policy associated with the resource110may specify or be configured to specify which type of attack a Verified push may be used as an alternative authentication technique.

According to some examples, the method400includes presenting, at a user access device, a prompt, wherein the prompt includes a unique code at step410. With reference to

FIG.3A, the user102may be presented with a code302, such as a six-digit code in various possible examples. The code302may be shown in a prompt300, and the prompt may be presented on the user's102access device, such as a laptop, when the push is initiated (or shortly thereafter). It should be noted that the verification prompt300may be any type of communication, for example, prompt300may be an email, a phone call, a picture, a text message, a generated user interface (GUI), combinations of the same, etc., in various possible examples.

According to some examples, the method400includes presenting, at a user authentication device, a verification interface, wherein the verification interface includes a code input box at step415. With reference toFIG.3B, an example prompt310for inputting the code302that may be presented to the user's102authentication device, such as a mobile device, is shown. It should be noted that the verification interface may be presented on the access device in various possible examples. In some examples, the authentication device and the access device may be the same device. The code302may be entered into the code verification boxes312. As previously discussed, the verification boxes312may be one or more input boxes capable of receiving the code302.

According to some examples, the method400includes receiving a verification signal, wherein the user authentication device sends the verification signal to at least one of the authentication device, the authentication service, and the resource at step420. It should be noted that the authentication device may be authentication device104and may be part of either the authentication service108, the user access device, the user authentication device, and/or the resource110. In some examples, the verification signal may be received from a 3rdparty service.

According to some examples, the method400includes determining, based on the verification signal, if the user account is authenticated at step425. In some examples the authentication device104may determine that the verification signal is authenticated. In some examples, the authentication service108and/or resource110may determine that the verification signal is authenticated.

According to some examples, the method400includes sending a verified signal associated with the user account to at least one of the authentication service and the resource at step430. It some examples, the verified signal may be sent to both the authentication service108and the resource110. In some examples, the verified signal is sent to the user access device. In some examples, the authentication service108and/or the resource110may clear or otherwise reset a period in which the authentication provider will require the user account to authenticate with the resource using the alternative authentication technique, such as Verified Push, after the verified signal is sent. In this regard, the user102account may be verified and allowed to access the resource110after the verified signal is sent.

FIG.5shows an example method500of one aspect of the present disclosure. According to some examples, the method500includes setting a threshold, wherein the threshold is associated with a number of requests for authentication of a user account at step505. In some examples, the authentication service108sets the threshold. In some examples, the resource110sets the threshold. In some examples, the threshold is set by a service administrator or an authentication provider administrator. In this regard, the threshold may be configurable and may be set according to a particular authentication technique.

According to some examples, the method500includes receiving at least one request for authentication, wherein the request is sent by the authentication service at step510. In some examples, any number of requests associated with the user102account may be received. The number of requests received may be tracked by the authentication device104, the authentication service108, the resource110, combinations of the same, etc., in various possible examples.

According to some examples, the method500includes determining, that the user account is under attack when greater than the threshold number of requests sent by the authentication service have failed to authenticate the user account at step515. In some examples, the system may determine that the user102account has denied a number of requests greater than the threshold. In some examples, authentication device104may determine that the particular authentication technique has failed verification and may provide the system, such as the authentication service108and/or resource110, a signal including the number of failed requests. In some examples, (as shown inFIG.6at step615) the system may determine that a number of requests greater than the threshold have timed out, i.e., the user102account has neither tried to verify nor deny the requests. It should be noted that the number of failed requests may be a combination of any failed, or timed-out, authentication technique associated with the user102account.

According to some examples, the method500includes requiring the user account to authenticate with the service using the alternative authentication technique that is less vulnerable to the ongoing attack at step520. In this regard, the user102account may not use any authentication technique available and may only use the alternate technique, or a choose between a list of alternate techniques, set by the authentication service108, rule or policy, resource110, administrator, combinations of the same, etc., in various possible examples.

Restricting the techniques may help mitigate the risks associated with an ongoing attack while still allowing the user102account to be authenticated thereby facilitating the user's102ability to continue working.

FIG.7shows an example of computing system700, which can be for example any computing device making up the access device114, authentication device104, authentication service108, resource110, or any component thereof in which the components of the system are in communication with each other using connection705. Connection705can be a physical connection via a bus, or a direct connection into processor710, such as in a chipset architecture. Connection705can also be a virtual connection, networked connection, or logical connection.

Example system700includes at least one processing unit (CPU or processor)710and connection705that couples various system components including system memory715, such as read only memory (ROM)720and random-access memory (RAM)725to processor710. Computing system700can include a cache of high-speed memory712connected directly with, in close proximity to, or integrated as part of processor710.

Processor710can include any general-purpose processor and a hardware service or software service, such as services732,734, and736stored in storage device730, configured to control processor710as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor710may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction, computing system700includes an input device745, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system700can also include output device735, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input/output to communicate with computing system700. Computing system700can include communications interface740, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

The storage device730can include software services, servers, services, etc., that when the code that defines such software is executed by the processor710, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor710, connection705, output device735, etc., to carry out the function.

Aspect 1. A method for altering an authentication technique in response to a detection of a possible attack to which the authentication technique is vulnerable, the method comprising: receiving an authentication request to authenticate to a resource, wherein the authentication to the resource is permitted using a particular authentication technique, wherein the authentication request includes contextual information associated with the first access device of the request and information identifying the resource; based on the contextual information, determining that the authentication request is subject to an ongoing attack; determining that the authentication request is subject to an ongoing attack; determining, an alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique; and an alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique; and requiring the first user account to authenticate with the resource using the alternative authentication technique that is less vulnerable to the ongoing attack than the particular authentication technique.

Aspect 2. The method of Aspect 1, wherein the authentication service is a multi-factor authentication service, and the particular authentication technique a multi-factor authentication technique, and the alternative authentication technique is an alternative multi-factor authentication technique.

Aspect 3. The method any of Aspects 1 to 2, wherein the authentication request is received after the first user account has completed a primary authentication technique on the first access device.

Aspect 4. The method of any Aspects 1 to 3, wherein the primary authentication technique is a username and password combination.

Aspect 5. The method of any of Aspects 1 to 4, further comprising: presenting a user interface for a primary authentication technique to authenticate the first user account with the resource; by the access device, a user interface for a primary authentication technique to authenticate the first user account with the resource; after successful completion of the primary authentication technique, sending the authentication request to the authentication service, wherein the contextual information associated with the first access device includes one or more of data identifying a network from which the access device is connected, the IP address of the access device, a browser version used to access the resource, an identification of browser extensions installed in the browser used to access the resource, an operating system on the access device, and a type of access device; determining, by the authentication service, based on the contextual information and the information identifying the resource that the particular authentication technique is permitted by a policy associated with the resource; and by the authentication service, based on the contextual information and the information identifying the resource that the particular authentication technique is permitted by a policy associated with the resource; and providing the particular authentication technique to the first user account; determining that the first user account failed the particular authentication technique.

Aspect 6. The method of any of Aspects 1 to 5, further comprising: prior to providing the particular authentication technique, offering options for at least two authentication techniques, wherein offering options for at least two authentication techniques, wherein the user account selects the particular authentication technique.

Aspect 7. The method of any of Aspects 1 to 6, wherein the determining that the first user account failed the particular authentication technique occurs prior to the determining that the authentication request is subject to an ongoing attack.

Aspect 8. The method of any of Aspects 1 to 7, further comprising: setting a period in which the authentication provider will require the user account to authenticate with the resource using the alternative authentication technique before allowing the user account to authentication with the particular authentication technique.

Aspect 9. The method of any of Aspects 1 to 8, further comprising: clearing the period in which the authentication provider will require the user account to authenticate with the resource using the alternative authentication technique after the user account successfully authenticates with the alternative authentication technique.

Aspect 10. The method of any of Aspects 1 to 9, wherein the resource is associated with an access policy configured at the authentication service, the access policy specifies a rule for determining that the authentication request is subject to an ongoing attack.

Aspect 11. The method of any of Aspects 1 to 10, wherein the particular authentication technique is a push to an authentication device, wherein the rule defines a threshold for a number of push requests sent by the authentication service that have timed-out, wherein the authentication service determines that the user account is under attack when greater than a threshold number of push requests sent by the authentication service have timed-out.

Aspect 12. The method of any of Aspects 1 to 11, wherein the particular authentication technique is a push to an authentication device, wherein the rule defines a threshold for a number of push requests sent by the authentication service that have been declined, wherein the authentication service determines that the user account is under attack when greater than a threshold number of push requests sent by the authentication service have been declined.

Aspect 13. The method of any of Aspects 1 to 12, wherein the particular authentication technique is a push to an authentication device, wherein the rule defines a threshold for a number of authentication requests received by the authentication service that originate from an IP address but are requested on behalf of different user accounts, wherein the authentication service determines the resource is under attack when the threshold is exceeded.

Aspect 14. The method of any of Aspects 1 to 13, wherein the particular authentication technique is a push to an authentication device, wherein the rule defines that when the user account is attempting to authenticate from an IP address not previously associated with the user account that the user account may be under attack.

Aspect 15. The method of any Aspects 1 to 14, wherein determination that the user account is under attack indicates at least one of a push fatigue attack, a brute force attack, an adversary-in-the-middle-attack, a passcode phishing attack, and a push harassment attack.

Aspect 16. The method of any of Aspects 1 to 15, wherein the access policy is defined by the resource.

Aspect 17. The method of any of Aspects 1 to 16, wherein some services will see the characteristics associated with some attacks as normal below individualized thresholds, such as if a service utilizes a VPN for access devices, the same user account may routinely attempt to authenticate from different IP addresses and this would be normal within a threshold configured by the service.

Aspect 18. The method of any of Aspects 1 to 17, wherein the access policy includes an attack mitigation requirement, the attack mitigation requirement defining when the alternative authentication technique should be applied to the user account, and when the alternative authentication technique should be applied to all requests for authentication to the resource.

Aspect 19. The method of any of Aspects 1 to 18, wherein the alternative authentication technique includes a multi-device push or authentication using WebAuthn.

Aspect 20. The method of any of Aspects 1 to 19, wherein the multi-device push includes: sending an access code to the access device for entry into the authentication device;

receiving the access code from the authentication device.