Defensive multi-factor authentication against phishing

Abstract

Techniques are disclosed that relate to detecting and preventing phishing attacks (e.g., man-in-the-middle attacks) related to multi-factor authentication (MFA) or two-factor authentication (2FA) processes. A system is described that determines whether to allow or deny a subsequent authentication step based on a trust level determined between a computing device that made an initial authentication request to a service computer system and a computing device (e.g., a mobile device) that is required to perform the subsequent authentication step (e.g., a 2FA authentication step). The computing device associated with the subsequent authentication step evaluates the trust between the devices and determines whether to allow or deny the subsequent authentication step. The techniques of the present disclosure enhance the security of computer systems against phishing attacks while maintaining a satisfactory user experience for legitimate users.

Description

Technical Field

[0001] This disclosure generally relates to methods for accessing online systems, and more specifically to assessing trust between devices during a multi-factor authentication security authentication process according to various embodiments. Background Technology

[0002] Online computer systems are ubiquitous today, offering a wide variety of services. For example, they may provide access to secure systems, files, accounts, the ability to execute financial transactions, and other functionalities through web interfaces. Unfortunately, online systems offering such functionality (including transaction processing systems) are vulnerable to malicious attempts to compromise account security and / or obtain unauthorized information. These malicious attempts can take many forms, including phishing attacks that attempt to obtain user account information to access the online system. The applicant recognizes the opportunity to provide improved authentication mechanisms and offers the solutions discussed below. Attached Figure Description

[0003] Figure 1 This is a block diagram of a system for determining trust between computing devices for an authentication process associated with a service computer system, according to some embodiments.

[0004] Figure 2 A representation of an example account login request page according to some embodiments is depicted.

[0005] Figure 3 A block diagram of a trust factor assessment module according to some embodiments is depicted.

[0006] Figure 4 A block diagram depicts an example of an embodiment of a phishing attack attempting to overcome the 2FA process.

[0007] Figure 5 A block diagram of a system according to some embodiments for detecting and preventing phishing attacks that attempt to overcome the 2FA process using a trust factor assessment module is depicted.

[0008] Figure 6 A block diagram of a system for processing legitimate requests, involving a trust factor assessment module on a computing device, is depicted.

[0009] Figure 7 This is a flowchart illustrating a method for determining whether to allow subsequent authentication steps according to some embodiments.

[0010] Figure 8 This is a flowchart illustrating another method for c according to some embodiments.

[0011] Figure 9 This is a flowchart illustrating a method for rejecting subsequent authentication steps according to some embodiments.

[0012] Figure 10 This is a block diagram of one embodiment of a computer system.

[0013] While the embodiments disclosed herein are readily adaptable to various modifications and alternatives, specific embodiments are illustrated by way of example in the accompanying drawings and described in detail herein. However, it should be understood that the drawings and their detailed description are not intended to limit the scope of the claims to the specific forms disclosed. Rather, this application is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure of this application as defined by the appended claims.

[0014] This disclosure includes references to "one embodiment," "specific embodiment," "some embodiments," "various embodiments," or "one embodiment." The appearance of the phrases "in one embodiment," "in a specific embodiment," "in some embodiments," "in various embodiments," or "in one embodiment" does not necessarily refer to the same embodiment. Specific features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.

[0015] The statement in the appended claims that an element is “configured to” perform one or more tasks expressly indicates that 35 U.S.SC § 112(f) is not invoked on that claim element. Therefore, none of the claims in this filing are intended to be interpreted as having means plus function. If the applicant wishes to invoke Section 112(f) during examination, the claim element will be stated using the structure “means for [performing function]”.

[0016] As used herein, the term "based on" is used to describe one or more factors that influence a determination. This term does not exclude the possibility that other factors may influence the determination. That is, the determination may be based solely on the specified factor, or on the specified factor along with other unspecified factors. Consider the phrase "based on A to determine B," which indicates that B is the factor used to determine A or influence the determination of A. This statement does not exclude the possibility that the determination of A may also be based on other factors, such as C. This statement is also intended to cover embodiments in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0017] As used in this article, the phrase "in response to" describes one or more factors that trigger an effect. This statement does not exclude the possibility that other factors may influence or otherwise trigger the effect. That is, the effect may be solely in response to these factors, or it may be in response to these specified factors as well as other unspecified factors.

[0018] As used herein, the terms “first,” “second,” etc., serve as labels for the nouns preceding them and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise stated. As used herein, the term “or” is used as an inclusive OR, not an exclusive OR. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, and any combination thereof (e.g., x and y, but no z). In some cases, the context of the use of the term “or” may indicate that it is used in an exclusive sense; for example, “choose one of x, y, or z” in this example means that only one of x, y, and z has been chosen.

[0019] In the following description, numerous specific details are set forth to provide a thorough understanding of the disclosed embodiments. However, those skilled in the art will recognize that various aspects of the disclosed embodiments can be practiced without these specific details. In some instances, well-known structures, computer program instructions, and techniques have not been shown in detail to avoid obscuring the disclosed embodiments. Detailed Implementation

[0020] This disclosure relates to various techniques for detecting and preventing malicious attempts to obtain confidential user account information in order to gain unauthorized access to online systems. Online systems (e.g., payment processing systems, social networking systems, etc.) may frequently be subject to malicious attempts to obtain access credentials for user accounts, such as phishing attacks. Phishing attacks (which may occur in phishing campaigns involving one or more specific phishing attacks against one or more accounts) may utilize electronic communications (e.g., email) to attempt to obtain confidential user account information by masquerading as a trusted communication. Phishing electronic communications may include, for example, email spoofing, instant messaging, or text messages that redirect users to fake web pages that request users to enter personal information, such as account login information. The fake web pages are created to look or feel like legitimate web pages of the online system. Phishing electronic communications can more broadly include any electronic communication designed to trick users into providing personal or confidential information in response to that electronic communication.

[0021] In attacks targeting online systems, phishing emails can be used to obtain account login information and gain unauthorized access to the online system by malicious actors. Once unauthorized access is gained, malicious actors may attempt to obtain private information, change accounts, or launch lateral attacks against other users with accounts on the online system.

[0022] Online systems, including transaction systems, are susceptible to numerous phishing attacks. Phishing attacks can be particularly abusive for transaction systems that process financial information for users, such as payment processing systems. Many online systems implement multi-factor authentication (MFA) (e.g., two-factor authentication (2FA)) to defend against phishing attacks. MFA or 2FA is considered highly resistant to phishing attacks. However, the inventors of this application have recognized that online systems using MFA or 2FA may still be vulnerable to certain types of phishing attacks. One example of a phishing attack that might defeat MFA or 2FA is a "man-in-the-middle (MITM)" attack. An MITM attack refers to an attacker intercepting one or more communications between two parties and using that information for malicious purposes. Note that, as used herein, the terms multi-factor authentication (MFA) and two-factor authentication (2FA) may be used interchangeably in some embodiments.

[0023] In short, a MITM (Made-to-Made-Method) attack in the context of a phishing attack might involve directing a user to a phishing webpage (e.g., via email communication) where the user enters their login credentials. The phishing webpage might then pass this information to an attacker's session to perform an actual login attempt, generating a 2FA (e.g., challenge request) on the user's device (e.g., a mobile device). The user then approves the 2FA request, thus granting the attacker access to the online system. The phishing webpage might then return a login error indication to the user, allowing them to retry. The user might be allowed to retry successfully to avoid suspicion of a MITM phishing attack. Figure 4 Further details of an example MITM phishing attack are provided in the illustrated embodiment.

[0024] Another example of a phishing attack that could potentially defeat MFA or 2FA attacks involves situations where a user indiscriminately approves an MFA or 2FA request. In this scenario, the user might receive a random 2FA request initiated by an attacker attempting to log into the user's account, rather than by the user themselves. If the user indiscriminately or instinctively approves the random 2FA request without realizing that they did not initiate the request, the attacker could potentially gain access to the user's account on the online system.

[0025] Detecting MITM phishing attacks and one or more attack sources can help prevent current or future attacks on online systems. However, current methods may struggle to detect MITM phishing attacks. Furthermore, even if a MITM phishing attack is detected, blocking access and stopping the attack can be difficult because it is not easy to distinguish between attack attempts and legitimate access attempts. This disclosure anticipates various techniques for detecting MITM phishing attacks (and other phishing attacks that may overcome MFA or 2FA) and preventing attacks from successfully gaining access to online systems while minimizing interference with legitimate user access attempts.

[0026] One embodiment described herein has two broad components: 1) evaluating a trust factor between a first computing device (e.g., a mobile device) and a second computing device, wherein the second computing device initiates an authentication process for an online system, and wherein the trust factor is evaluated by the first computing device based on authentication information received during an authentication step (first authentication step) in the authentication process performed on the second computing device and authentication information stored by the first computing device; and 2) prohibiting the execution of an authentication step (e.g., a 2FA authentication step) on the first computing device when there is insufficient trust between the first and second computing devices based on the evaluated trust factor. As used herein, the term “trust factor” refers to an indication (e.g., a trust level) of trust between devices determined based on an evaluation of information or data associated with the devices. Examples of trust factors include, but are not limited to, scalar or discrete values ​​that provide a metric of trust between devices, or values ​​associated with a binary decision (e.g., values ​​0 or 1), or multiple discrete or defined values ​​(e.g., “low,” “medium,” and “high”). In the embodiment described herein, evaluating the trust factor includes: evaluating comparable data in the authentication information received during the first authentication step and the authentication information stored by the first computing device. Examples of comparable data include Internet Protocol (IP) addresses (LAN or WAN addresses), geographic location, credential information, cookies, digital tokens (e.g., autofill tokens), or challenge keys (e.g., proxies or credentials on client-side devices or browsers). In various embodiments, a first computing device may refuse to perform a 2FA authentication step on its own device when the assessed trust factor does not meet a specified threshold. Additionally, the first computing device may provide an indication to an online system that a 2FA authentication step has been refused and a security incident has occurred. In some embodiments, the online system may provide a diversionary notification to a second computing device to conceal a phishing attack from an attacker.

[0027] In short, the inventors of this application have recognized the benefits of detecting phishing attacks on the MFA / 2FA process by determining the second (or subsequent) authentication step based on a computing device. The computing device used for the secondary authentication step can determine the trust between itself and another computing device initiating the MFA / 2FA process. This determined trust can then be used to allow or deny the secondary authentication step on the computing device used for secondary authentication. By determining trust and deciding to allow or deny the secondary authentication step on the computing device used for the secondary authentication step, previously undetected phishing attacks can be detected. Furthermore, phishing attacks can be detected and blocked (e.g., denied) without the knowledge of the legitimate user or attacker. For example, when a phishing attack is detected and blocked, the legitimate user may never see the secondary authentication step. By hiding the fact that an attack has been detected on a redirect page (or other disguise), the attacker remains unaware of the detection result.

[0028] Figure 1 This is a block diagram of a system, according to some embodiments, for determining trust between computing devices for an authentication process associated with a serving computer system. Figure 1 In the illustrated embodiment, system 100 includes a service computer system 102, a computing device 104, and a computing device 106. As used herein, the term "service computer system" refers to any computer system that implements a service, in which two or more parties use the computer system to exchange information. Therefore, a "service" according to this disclosure can include transaction services, payment services (e.g., PayPal), social networks, file transfer services, online retailers, dating websites, etc. Note that, in general, this disclosure can include various examples and discussions of technologies and structures in the context of "service computer system." Note that all these examples, technologies, and structures are generally applicable to any online system that allows access requests (e.g., authentication process requests) and information exchange to provide services to users. For example, in some cases, service computer system 102 can be any online system. However, the term service computer system is used in various parts of this disclosure for ease of understanding.

[0029] Computing devices 104 and 106 may be user computing devices. For example, computing device 104 or 106 may be a client computing device used by a user to access one or more user accounts located on the service computer system 106 and to exchange information with the service computer system. In some embodiments, requests by computing device 104 or 106 to access one or more user accounts include user account login requests or other access requests, which may be to access specific resources or functions without referencing a specific user account. Computing devices 104 and 106 may communicate with the service computer system 102 via a wide area network such as the Internet. However, communication may also occur via a computer network coupled to the service computer system 102.

[0030] In some embodiments, a user uses an account login request page (e.g., an interface) to attempt to access a user account on service computer system 102. The user can access the account login request page via a web browser on computing device 104 or computing device 106. For example, a user can remotely access the account login request page displayed in a web browser. The user can then attempt to log in to service computer system 102 using the account login request page displayed in the web browser. Other embodiments for accessing the account login request page are also contemplated, as this disclosure is not limited to these specific examples.

[0031] Figure 2 A representation of an example account login request page according to some embodiments is depicted. The account login request interface 200 may include one or more data input fields 202 (e.g., data input fields 202A, 202B, 202C, and 202D, or collectively “202A-D”). In some embodiments, the data input field 202 is a field that requests the input of profile information associated with a user requesting login access to the transaction system 100. The data input field 202 may be, for example, a fillable form data input field or a drop-down menu data field (e.g., a form input button). In some embodiments, the data input field 202 may request the user's account login credentials for the service computer system 102. For example, as... Figure 2 As shown, data input field 202A can request the username of a user account, and data input field 202B can request the password associated with the username. Other embodiments of requests to data input field 202 are also contemplated, as this disclosure is not limited to these specific examples. Examples of other requests to data input field 202 include, but are not limited to, email addresses, postal codes, phone numbers, PIN codes, dates of birth, challenge questions (e.g., answers to specific questions previously posed to the user during account creation), and input implemented to verify human input (e.g., security procedures such as CAPTCHA processes).

[0032] Back Figure 1 In the illustrated embodiment, computing device 104 initiates an authentication process request (e.g., an account login request) to serving computer system 102. In response to receiving the authentication process request, serving computer system 102 can operate the login request process via an account login request page on a web browser on computing device 104. The login request process may include exchanging information between computing device 104 and serving computer system 102 to attempt to authenticate a user account on the serving computer system. The information that may be exchanged includes, but is not limited to, the username, password, Internet Protocol (IP) address (LAN or WAN address) of computing device 104, the geographic location of computing device 104, cookie information on computing device 104, challenge keys (e.g., credentials or proxies on client-side devices or browsers), digital tokens (e.g., autofill tokens), and other data input requests described herein.

[0033] The service computer system 102 can evaluate the information exchanged during the login request process to determine whether to approve or deny the login request from the computing device 104. In some embodiments, such as Figure 1 As shown, the service computer system 102 implements a multi-factor authentication (MFA) process or a two-factor authentication (2FA) process when determining whether to approve or deny a login request from computing device 104. As used herein, a multi-factor authentication (MFA) process is an electronic authentication process in which access is granted only after two or more security factors (e.g., evidence) have been authenticated (e.g., the user is authenticated). Authenticated security factors may include, but are not limited to, knowledge (e.g., something only the user knows, such as a username / password), ownership (e.g., something only the user owns, such as a mobile device), and inheritance (e.g., something only the user can access). As used herein, a two-factor authentication (2FA) process is a subset of MFA in which access is granted after two security factors have been authenticated. Both MFA and 2FA processes can be implemented using a single computing device or multiple computing devices.

[0034] In embodiments with an MFA or 2FA process, the login request process between the serving computer system 102 and the computing device 104 is an “initial authentication step” (e.g., a first authentication step) within the MFA / 2FA process. In the illustrated embodiment, the serving computer system 102 contacts the computing device 106 to request a “subsequent authentication step” within the MFA or 2FA process. In a 2FA process embodiment, the subsequent authentication step can be the second and final step in the authentication process. In an MFA process embodiment, the subsequent authentication step can be any step following the initial step in the authentication process. For example, a subsequent authentication step can be a final authentication step performed after one or more intermediate authentication steps, or it can be an intermediate authentication step.

[0035] In some embodiments, computing device 106 is a trusted device authorized to provide subsequent authentication steps in an MFA or 2FA process for a user account that is being attempted to be accessed. For example, computing device 106 may be a pre-designated device to be contacted to implement an MFA or 2FA process for a user account that is being attempted to be accessed. In some embodiments, computing device 106 is a device identified by the user during the account creation process and used as a device for the MFA or 2FA process.

[0036] In some embodiments, computing device 106 is a mobile device. A mobile device can be a small, multi-purpose computing device, including any of a variety of computer system devices that are mobile or portable and capable of performing wireless communications. Examples of mobile devices include, but are not limited to, mobile phones, smartphones, tablets or tablet computing devices, laptops, netbooks, notebook computers, mini-notebooks, and ultrabooks. Other various types of devices may also fall into this category if they include wireless or RF communication capabilities (e.g., Wi-Fi, cellular, and / or Bluetooth), such as portable gaming devices, portable internet devices, and other handheld devices and wearable devices. As described herein, the term "mobile device" can be defined as including any multi-purpose electronic, computing, and / or telecommunications device (or combination of devices) that is easily carried by a user and capable of wireless communications (e.g., using WLAN, Wi-Fi, cellular, and / or Bluetooth), wherein the primary purpose of the device is telecommunications, computing, and / or video gaming.

[0037] In the illustrated embodiment, computing device 106 includes a trust factor assessment module 108 and an authentication implementation module 110. In some embodiments, the trust factor assessment module 108 and the authentication implementation module 110 may be implemented in an application associated with the service computer system 102 (e.g., an API associated with the service computer system 102). Subsequent authentication step requests from the service computer system 102 are received in the trust factor assessment module 108 on computing device 106. In some embodiments, the subsequent authentication step requests include information about computing device 104 and the initial authentication steps. For example, the information in the subsequent authentication step requests may include, but is not limited to, the Internet Protocol (IP) address (LAN address or WAN address) of computing device 104, the geographic location of computing device 104, cookie information about computing device 104, the challenge key result of computing device 104 (e.g., credentials or proxies on client devices or browsers) or digital tokens (e.g., autofill tokens and autofill delays).

[0038] Figure 3 A block diagram of a trust factor assessment module 108 according to some embodiments is depicted. The trust factor assessment module 108 can assess trust factors (such as trust between computing device 106 and computing device 104) Figure 1 (As shown by the dashed lines in the diagram). In some embodiments, the trust factor assessment module 108 includes a trust factor determination module 300 and a trust factor comparison module 302. The trust factor determination module 300 can receive information about the computing device 104 and the initial authentication step from a subsequent authentication step request. The trust factor determination module 300 can also access or receive information about the computing device 106 (e.g., from memory on the computing device or other systems). The information about the computing device 106 may include data comparable to the information about the computing device 104 and the initial authentication step. For example, the information about the computing device 106 may include, but is not limited to, the Internet Protocol (IP) address (LAN address or WAN address) of the computing device 106, the geographic location of the computing device 106 (based on GPS, GSM, or WiFi location), cookie information on the computing device 106, the challenge key result of the computing device 106 (e.g., credentials or proxies on client-side devices or browsers) or digital tokens (e.g., autofill tokens and autofill delay).

[0039] In some embodiments, the trust factor determination module 300 evaluates comparable data from information about computing device 104 and the initial authentication steps, as well as information about computing device 106, to determine one or more trust factors between computing device 106 and computing device 104. For example, the similarity or matching between comparable data may be evaluated to determine one or more trust factors between computing device 106 and computing device 104. In some embodiments, the closer the similarity between comparable data (e.g., the closer the matching), the higher the trust factor between computing device 106 and computing device 104.

[0040] In the illustrated embodiment, the determined trust factors(s) are provided to the trust factor comparison module 302. The trust factor comparison module 302 can compare the determined trust factors(s) with one or more specified thresholds to determine whether to allow or deny subsequent authentication steps. For example, if the determined trust factors(s) meet one or more specified thresholds (e.g., the trust factors(s) are higher than one or more specified thresholds), the trust factor comparison module 302 allows subsequent authentication steps (and the trust factor evaluation module 108 outputs an indication to the authentication process implementation module 110 allowing subsequent authentication steps, such as...). Figure 1 (As shown). If the identified trust factors(one or more) fail to meet(one or more) specified thresholds (e.g.,(one or more) trust factors are below(one or more) specified thresholds), the trust factor comparison module 302 refuses to proceed with subsequent authentication steps (and the trust factor evaluation module 108 may output an indication to the service computer system 102 to refuse subsequent authentication steps, such as...). Figure 1 (As shown).

[0041] As described herein, the determination and output of allowing or denying the continuation of subsequent authentication steps are made without the user's knowledge that a decision is being made, rather than when the subsequent authentication step is allowed and the user interacts with computing device 106 to complete the subsequent authentication step. Furthermore, the decision made by the trust factor assessment module 108 on computing device 106 is made without any communication between computing device 106 and computing device 104. Therefore, when a subsequent authentication step is denied, neither the user of computing device 106 nor the user of computing device 104 may be aware of the decision being made by computing device 106 or any denial that has occurred. The only decision that may be apparent to the user of computing device 106 is when the subsequent authentication step is allowed and computing device 106 prompts the user to continue with the subsequent authentication step. Moreover, as described herein, the decision to allow or deny the subsequent authentication step is made on computing device 106, and no additional interaction between computing device 106 and the service computer system 102 is required after computing device 106 receives the request for a subsequent authentication step. Allowing computing device 106 to determine whether to allow or deny subsequent authentication steps without additional communication with the service computer system 102 improves the speed and efficiency of the decision to allow or deny, thereby creating a better user experience.

[0042] In some embodiments, one or more specified thresholds are predetermined on computing device 106. For example, one or more specified thresholds may be determined by an application running on computing device 106 (e.g., an API associated with the service computer system 102). In some embodiments, one or more specified thresholds may vary on computing device 106. For example, one or more specified thresholds may be changed based on the location of computing device 106 (e.g., whether the computing device is on a known WAN). One or more specified thresholds may also be updated or changed after allowing or denying subsequent authentication steps.

[0043] Returning to the trust factor determination module 300, trust factors(s) can be determined based on various evaluation scenarios of comparable data from computing devices 106 and 104. The specified thresholds(s)(s) used in the trust factor comparison module 302 can also vary depending on the various evaluation scenarios of the comparable data implemented in the trust factor determination module 300. Various embodiments of the evaluation scenarios of comparable data for determining (one or more) trust factors(s) and their corresponding specified thresholds(s) are contemplated herein.

[0044] In some anticipated embodiments, a single set of comparable data is used to determine the trust factor. As an example, the location of computing device 104 can be compared with the location of computing device 106 to determine the trust factor. This location can be determined based on data such as GPS data for each computing device or other location-based data such as ASN (Autonomous System Number). In such embodiments, the closer the locations of the computing devices, the higher the trust factor. Additionally, specifying a threshold can correspond to an allowable distance range between computing device 104 and computing device 106 to ensure a level of secure trust between the devices.

[0045] In other anticipated embodiments, a single set of comparable data is used to determine a trust factor, and this comparable data is used for binary decision-making to determine whether to allow or deny subsequent authentication steps. For example, an evaluation of the WAN IP address of computing device 104 and the WAN IP address of computing device 106 can be used to determine whether to allow or deny subsequent authentication steps. In such an embodiment, the trust factor is determined based on whether the WAN IP address of computing device 104 matches the WAN IP address of computing device 106; if the addresses do not match, the trust factor is 0, and if the addresses match, the trust factor is 1. A specified threshold can then be determined based on this binary value to determine whether it is met or not. Other examples of comparable data that can be used for binary decision-making include, but are not limited to, LAN IP addresses, device fingerprints (e.g., based on the device fingerprints of computing devices 104 and 106, such as media access control (MAC) addresses), which are the same devices.

[0046] In other anticipated embodiments, a trust factor is determined by using trust factors from an individual comparable data set and combining these trust factors to determine an overall trust factor. For example, the trust determination module 300 may determine a first trust factor from the GPS locations of computing devices 104 and 106, and a second trust factor from the GSM-based locations or WiFi signals of computing devices 104 and 106. The first and second trust factors may be combined to determine an overall trust factor, which is compared to a specified threshold in the trust factor comparison module 302. In some embodiments, the overall trust factor is determined based on a combination of individual comparable data sets. For example, the overall trust factor may be determined based on a combination of the GPS locations and GSM-based locations or WiFi signals of computing devices 104 and 106.

[0047] In some anticipated embodiments, the trust factor comparison module 302 compares an individual trust factor with an individual threshold. For example, as described above, the trust determination module 300 may determine a first trust factor and a second trust factor based on different locations. In the trust factor comparison module 302, the first trust factor may be compared with a first specified threshold, and the second trust factor may be compared with a second specified threshold. The determination of whether to allow or deny subsequent authentication steps may be based on two comparisons. For example, both the first and second trust factors may need to meet their respective trust thresholds to allow subsequent authentication steps. Therefore, if either the first or second trust factor fails to meet its corresponding specified threshold, the subsequent authentication step is denied.

[0048] In some anticipated embodiments, trust factors can be determined based on whether a trusted association exists between computing device 106 and computing device 104. For example, an email account used on computing device 106 can be compared with an email account used on computing device 104. If these computing devices are logged into the same email account, a high level of trust can be determined between these computing devices. If these email accounts are associated with a trusted service (e.g., the email accounts are associated with service computer system 102), further trust can be determined.

[0049] Another trusted association scenario between computing device 106 and computing device 104 could be whether the IP address (WAN or LAN) of computing device 104 has been used in a previous determination. For example, if the IP address has been used before, a higher trust factor may be generated. As another example, if the IP address accesses an email account associated with computing device 106, a higher trust factor may be generated. In another anticipated embodiment, the delay in providing information can be used to determine the trust factor. For example, a digital token can be used to automatically populate data input fields during the authentication step. The delay in populating the data input fields can be used to determine the trust factor (a higher or lower delay may indicate greater trust, depending on the scenario being evaluated).

[0050] In some embodiments, computing device 106 may need to request additional information from serving computer system 102 to determine one or more trust factors. For example, computing device 106 may need information about the reputation of IP addresses (e.g., whether the IP address has been flagged for suspicious behavior toward serving computer system 102).

[0051] While this document describes various possible scenarios for determining one or more trust factors and comparing them to their corresponding specified thresholds, it should be understood that those skilled in the art can anticipate other scenarios for determining one or more trust factors and comparing them to their corresponding specified thresholds based on the description herein. For example, combinations of any of the various possible scenarios described herein can be anticipated for determining one or more trust factors and comparing them to their corresponding specified thresholds.

[0052] Back Figure 1 The trust factor assessment module 108 may only need to assess trust factors once or periodically between a specific computing device 104 (e.g., the computing device initiating the authentication process) and computing device 106 (e.g., the computing device determining whether to allow or deny subsequent authentication steps in the MFA / 2FA process). For example, once trust is established between computing devices 104 with certain specific identification information (e.g., a specific device fingerprint), the established trust between computing devices 104 and 106 may be permanent or valid for a specified period of time. Therefore, when computing device 106 receives a request for subsequent authentication steps associated with computing device 104, computing device 106 can proceed more quickly to allow the subsequent authentication steps. Information about the previous determination of trust can be stored, for example, in the memory of computing device 106 for retrieval upon receiving a request for subsequent authentication steps.

[0053] As stated herein, the inventors of this application have recognized that Figure 1 The implementation of System 100 shown herein can help detect and prevent phishing attacks that attempt to bypass the MFA or 2FA process. System 100 can automatically detect and prevent phishing attacks without the knowledge of the attempted attack by a legitimate user (e.g., a user of computing device 106) (e.g., the user may not know that subsequent authentication steps were rejected in response to the attempted attack). Furthermore, as described herein, System 100 can also detect and prevent phishing attacks without the knowledge that an attacker (e.g., a malicious user of computing device 104) has been detected and is being blocked by computing device 106.

[0054] Figure 4An example of an embodiment of a phishing attack attempting to overcome the 2FA process is depicted. In attack 400, user 402 initiates an authentication process request on computing device 401 via phishing email 404. Phishing email 404 may be, for example, an email sent by an attacker associated with computing device 104, prompting user 402 to log in or attempt to log in to their account on the service computer system 102. However, phishing email 404 redirects user 402 to a phishing page 406 (which is associated with or controlled by computing device 104) instead of the legitimate page 408. Phishing page 406 may be accessed by user 402 via a web browser on user computing device 401. For example, phishing page 406 may be a page designed to look similar to legitimate page 408 (e.g., a legitimate account login request page associated with the service computer system) and request the same information (e.g., data entry). Since phishing page 406 is generated by an attacker using computing device 104, the IP address and / or other information (such as location) of phishing page 406 are usually different from similar information on computing device 401.

[0055] When user 402 provides his / her authentication information (such as username and password) on phishing page 406, the phishing page can forward that information in real time to legitimate page 408 (which is associated with or controlled by the service computer system 102) and input that information as part of the initial authentication process. This information and the initial authentication process can be provided to legitimate page 408 directly from the phishing page 406 on the web browser itself or via computing device 104 (e.g., by an attacker using computing device 104). Since the phishing page 406 associated with computing device 104 is providing the initial authentication process to legitimate page 408, information about phishing page 406 and computing device 104 (such as IP address or other information described herein) can be included as part of the initial authentication process.

[0056] At the service computer system 102, the initial authentication steps and the information contained therein are received. Since the information received in the initial authentication steps is the actual authentication information of user 402, the service computer system 102 verifies that the initial authentication steps are legitimate. Through a 2FA process on the service computer system 102, the service computer system then generates a request for a subsequent authentication step 410 (e.g., a second-factor authentication request) for computing device 106, which is a computing device known to be associated with user 402. For example, computing device 106 may have been designated as a trusted device for user 402 during the setup of the user's account on the service computer system 102. The service computer system 102 provides the request to computing device 106 so that user 402 can complete the subsequent authentication step 410 on computing device 106.

[0057] In the illustrated embodiment, user 402 approves subsequent authentication step 410 on computing device 106, thus authorizing the attacker to authenticate with the service computer system 102. The attacker thereby gains access to the service computer system 102 in an authenticated attacker session 412. In some cases, to conceal the attack, phishing page 406 (or computing device 104) redirects the user to a legitimate page 408 and prompts them to retry the authentication process. The user can then be authenticated in the retry (with or without completing subsequent authentication step 410 during the retry) and gain access to the service computer system in an authenticated user session 414. Directing user 402 to retry the authentication process conceals the attacker's authentication in previous attempts, as the user may be led to believe that a user error is the reason for the need to retry the authentication process. In some cases, attack 400 can be described as a "man-in-the-middle" attack because phishing page 406 acts as an intermediary between user 402 and legitimate page 408.

[0058] As described in this article, the trust factor assessment module 108 ( Figure 1 and Figure 3 (As shown) can be implemented on computing device 106 to detect and prevent phishing attacks, for example Figure 4 The attack described in the text is 400. Figure 5A block diagram of a system, according to some embodiments, for detecting and preventing phishing attacks attempting to overcome the 2FA process using a trust factor assessment module 108 on a computing device 106. In attack defense 500, the trust factor assessment module 108 is implemented on the computing device 106. Therefore, when the computing device 106 receives a request for a subsequent authentication step from the service computer system 102, the request is received in the trust factor assessment module 108. As described herein, information about the phishing page 406 or the computing device 104 is included in the request for the subsequent authentication step. As described above, information about the phishing page 406 or the computing device 104 is included in the initial authentication step between the phishing page 406 and the legitimate page 408.

[0059] In Attack Defense 500, the Trust Factor Assessment Module 108 assesses that one or more trust factors between computing device 106 and computing device 104 fail to meet one or more specified thresholds. A lack of trust between computing device 106 and computing device 104 can indicate a phishing attack against user 402. If one or more trust factors fail to meet one or more specified thresholds, the Trust Factor Assessment Module 108 may refuse to perform subsequent authentication steps on computing device 106, as described herein. Furthermore, as... Figure 5 As shown, the trust factor assessment module 108 provides the service computer system 102 with an indication to deny the request for subsequent authentication steps. In some embodiments, the service computer system 102 denies the computing device 104 access to the service computer system (via the authentication process) in response to receiving the denial indication from the computing device 106.

[0060] In some embodiments, the service computer system 102 provides a diversion notice to the phishing page 406 (associated with the computing device 104) in response to receiving an instruction from the trust factor assessment module 108 to deny a request for further authentication steps. The diversion notice may be, for example, a false "pending authentication" notification for the phishing page 406. The diversion notice can be used to mislead an attacker, making them unaware that an attack has been detected. After a specified period of time, the diversion notice may be removed (e.g., stopped) to give the appearance that the request has timed out, further masking the detection of the attack. In some embodiments, the service computer system 102 provides a security notification in response to receiving an instruction from the trust factor assessment module 108 to deny a request for further authentication steps. The security notification may be, for example, notifying the owner or operator of the service computer system 102 that a security incident (e.g., a phishing attack) has occurred so that further investigation can begin or steps such as blocking the IP address of the phishing page 406 or the computing device 104 can be taken.

[0061] In some embodiments, the serving computer system 102 may take additional actions in response to receiving an indication to deny subsequent authentication steps. For example, the serving computer system 102 may implement additional authentication steps to determine the identity of the computing device 104. These additional authentication steps may be implemented to determine whether the computing device 104 is part of a phishing attack (e.g., a MITM attack) or whether the state of user 402 has undergone certain changes that cause (one or more) trust factors(s) to fail to meet (one or more) specified thresholds(s). In such instances, for example, user 402 may have recently moved, changed devices, or made other changes that cause (one or more) trust factors(s) determined by the assessment to fail to meet (one or more) specified thresholds(s). Therefore, the additional authentication steps implemented by the serving computer system 102 can be used to update or ensure trust between computing device 106 and computing device 104.

[0062] like Figure 5 As shown, the trust factor assessment module 108 (also in Figure 1 and 3 (As shown in the diagram) A trust factor assessment module 108 is implemented on computing device 106 to detect and prevent phishing attacks. A trust factor assessment module 108 is also implemented to allow legitimate access to the service computer system 102. Figure 6 A block diagram of a system for processing legitimate requests, involving a trust factor assessment module 108 on computing device 106, is depicted. In the embodiment of the legitimate request 600 shown, user 402 initiates and completes an initial authentication step for a legitimate page 408 via computing device 104. For example, user 402 can access the legitimate page 408 via a web browser on computing device 104 to initiate and complete the initial authentication step. As described herein, the initial authentication step also includes information about computing device 104.

[0063] In response to the initial authentication step, the service computer system 102 generates a subsequent authentication request and sends it to the computing device 106. When the computing device 106 receives the subsequent authentication step request from the service computer system 102, the request is received in the trust factor assessment module 108. As described herein, information about the computing device 104 is included in the subsequent authentication step request.

[0064] In the legitimate request 600, the trust factor assessment module 108 assesses that one or more trust factors between computing device 106 and computing device 104 meet one or more specified thresholds. Therefore, a security trust level exists between computing device 106 and computing device 104, and computing device 104 is thus considered a trusted device. In some embodiments, as described above, computing device 106 and computing device 104 may have already established a trust known to the trust factor assessment module 108. If one or more trust factors meet one or more specified thresholds, the trust factor assessment module 108 allows subsequent authentication steps to be performed on computing device 106. When the subsequent authentication steps are completed and successful, the user is authenticated and authorized to access the service computer system 102 (via legitimate page 408) in the authenticated user session 414.

[0065] Back Figure 1 In the illustrated embodiment, when one or more trust factors meet one or more specified thresholds or when prior trust exists between computing devices 106, the trust factor evaluation module 108 sends an indication to allow subsequent authentication steps to the authentication process implementation module 110, which is aware of the computing device 104. The authentication process implementation module 110 can then operate the subsequent authentication steps via, for example, the user interface (UI) of the computing device 106.

[0066] In some embodiments, subsequent authentication steps include requesting authentication information from the user and evaluating the authentication information based on the authentication information stored on the computing device 106. For example, subsequent authentication steps may include a minor step in an MFA or 2FA process whereby the computing device 106 authenticates the user based on information stored on the device. In some embodiments, the computing device 106 may contact the service computer system 102 and request information from it to complete the authentication steps.

[0067] like Figure 1As shown, system 100 includes an implementation of a trust factor assessment module 108 on computing device 106 to assess one or more trust factors between computing device 106 and computing device 104 when computing device 104 provides an authentication process request to service computer system 102 in an attempt to access a user account on the service computer system. As described herein, the implementation of the trust factor assessment module 108 on computing device 106 allows system 100 to allow or deny subsequent authentication requests (e.g., minor steps in an MFA or 2FA process) issued by device 106 and computing device (e.g., computing device 104) to service computer system 102 based on the trust level between the computing devices. Therefore, implementing the trust factor assessment module 108 on computing device 106 allows for the detection and prevention of phishing attacks (e.g., man-in-the-middle attacks) during an MFA or 2FA process without degrading the user experience of legitimate access attempts to the service by computer system 102.

[0068] Example Method

[0069] Figure 7 This is a flowchart illustrating a method for determining whether to allow subsequent authentication steps, according to some embodiments. In addition to other devices, such as... Figure 7 The methods shown can be used in conjunction with any computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the method elements shown may be performed simultaneously in a different order than shown, or may be omitted. Additional method elements may also be performed as needed. In various embodiments, some or all of the methods may be performed by a particular computer system, such as computing device 1010, as described below.

[0070] In 702, in the illustrated embodiment, after a previous authentication step in the authentication process, the first computing device receives a request to perform a subsequent authentication step in the authentication process to authenticate the user to the serving computer system, wherein the request includes information related to the first authentication and the previous authentication steps, and wherein the authentication process is initiated by the second computing device.

[0071] In 704, in the illustrated embodiment, the first computing device determines whether to allow subsequent authentication steps to be performed on the first computing device.

[0072] In embodiment 706, the first computing device evaluates a trust factor between itself and the second computing device based on first authentication information received by the first computing device and second authentication information stored by the first computing device. In some embodiments, evaluating the trust factor between the first and second computing devices includes assessing the similarity between comparable data in the first and second authentication information. In some embodiments, evaluating the trust factor includes assessing individual trust factors for at least two comparable data points and determining a trust factor based on a combination of individual trust factors.

[0073] In 708, in the illustrated embodiment, the first computing device prohibits the execution of subsequent authentication steps based on an evaluated trust factor. In some embodiments, the first computing device refuses to execute subsequent authentication steps based on an evaluated trust factor. In some embodiments, determining whether to allow subsequent authentication steps to be executed on the first computing device includes evaluating individual trust factors of at least two comparable data points and prohibiting subsequent authentication steps on the first computing device when at least one individual trust factor fails to meet a specified threshold for at least one individual trust factor. In some embodiments, the specified threshold is a value of a trust factor determined to correspond to a security trust level between the first and second computing devices.

[0074] In some embodiments, based on the prohibition of subsequent authentication steps, the first computing device determines that the authentication process is associated with a man-in-the-middle attack. In some embodiments, the first computing device allows subsequent authentication steps to be performed on the first computing device in response to the assessed trust factor meeting a specified threshold. In some embodiments, the first computing device transmits an indication to the serving computer system of the determination result regarding whether to allow subsequent authentication steps to be performed on the first computing device.

[0075] Figure 8 This is a flowchart illustrating another method for determining whether to allow subsequent authentication steps, according to some embodiments. Among other devices, such as... Figure 8 The methods shown can be used in conjunction with any computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the method elements shown may be performed simultaneously in a different order than shown, or may be omitted. Additional method elements may also be performed as needed. In various embodiments, some or all of the methods may be performed by a particular computer system, such as computing device 1010, as described below.

[0076] In 802, in the illustrated embodiment, the computing device receives a request to perform subsequent authentication steps in an authentication process to authenticate a user to the serving computer system, based on a previous authentication step in an authentication process initiated by an additional computing device, the request including first authentication information related to the previous authentication steps.

[0077] In 804, in the illustrated embodiment, the computing device determines a trust factor between the computing device and an attached computing device based on first authentication information received by the computing device and second authentication information stored by the computing device. In some embodiments, the trust factor is determined based on an evaluation of matches between comparable data in the first and second authentication information. In some embodiments, a match is determined for each of at least two comparable data, wherein the trust factor is determined based on a combination of matches determined for the at least two comparable data. In some embodiments, determining whether to allow subsequent authentication steps to be performed on the first computing device includes: evaluating an individual trust factor against at least two comparable data, and prohibiting the performance of subsequent authentication steps if each evaluated individual trust factor fails to meet a threshold specified for the individual trust factor.

[0078] In 806, in the illustrated embodiment, in response to a trust factor meeting a specified threshold, the computing device allows subsequent authentication steps to be performed. In some embodiments, the subsequent authentication steps include requesting authentication information from the user and evaluating the authentication information from the user based on second authentication information stored on the computing device.

[0079] In step 808, in the illustrated embodiment, in response to the trust factor failing to meet a specified threshold, the computing device prohibits the execution of subsequent authentication steps. In some embodiments, in response to prohibiting the execution of subsequent authentication steps, the computing device transmits an indication that subsequent authentication steps are prohibited to the serving computer system.

[0080] In some embodiments, the computing device stores a trust factor determined between the computing device and an additional computing device when the trust factor meets a specified threshold, wherein the computing device accesses the trust factor in response to receiving at least one additional request initiated by the additional computing device to perform a subsequent authentication step of the authentication process.

[0081] Figure 9 This is a flowchart illustrating a method for rejecting subsequent authentication steps according to some embodiments. For example... Figure 9 The methods shown can be used in conjunction with any computer circuits, systems, devices, elements or components, and other devices disclosed herein. In various embodiments, some of the method elements shown may be performed simultaneously in a different order than that shown, or may be omitted. Additional method elements may also be performed as needed. In various embodiments, some or all of the elements of the method may be performed by a particular computer system, such as computing device 1010.

[0082] In 902, in the illustrated embodiment, the serving computer system receives an initial authentication step of an authentication process used to authenticate a user to the serving computer system.

[0083] In 904, in the illustrated embodiment, the serving computer system sends a request for a secondary authentication step to a second client computing device, wherein the second client computing device is associated with a user, and wherein the request includes first authentication information related to the initial authentication step of the first client computing device.

[0084] In embodiment 906, the serving computer system receives an indication from the second client computing device that the second client computing device has determined, in response to a request, that the trust factor between the second client computing device and the first client computing device has failed to meet a specified threshold, wherein the trust factor is determined by the second client computing device based on first authentication information and second authentication information stored by the second client computing device. In some embodiments, the indication received from the second client computing device is an indication of a man-in-the-middle attack by the first client computing device against the serving computer system.

[0085] In 908, in the illustrated embodiment, based on this instruction, the serving computer system denies the first client computing device access to the serving computer system via the authentication process. In some embodiments, the serving computer system provides a transfer of attention notification to the first client computing device based on an instruction received from the second client computing device. In some embodiments, the transfer of attention notification includes a notification that the authentication process is pending, and wherein the transfer of attention notification is removed after a specified period of time. In some embodiments, the serving computer system initiates a security notification corresponding to the first client computing device based on an instruction received from the second client computing device.

[0086] Example computer system

[0087] Turn now Figure 10 This diagram depicts a block diagram of one embodiment of a computing device (which may also be referred to as a computing system) 1010. The computing device 1010 can be used to implement various parts of this disclosure. The computing device 1010 can be any suitable device type, including but not limited to personal computer systems, desktop computers, laptop or notebook computers, mainframe computer systems, network servers, workstations, or network computers. As shown, the computing device 1010 includes a processing unit 1050, a memory 1012, and an input / output (I / O) interface 1030 coupled via an interconnect 1060 (e.g., a system bus). The I / O interface 1030 can be coupled to one or more I / O devices 1040. The computing device 1010 also includes a network interface 1032, which can be coupled to a network 1020 for communication with, for example, other computing devices.

[0088] In various embodiments, processing unit 1050 includes one or more processors. In some embodiments, processing unit 1050 includes one or more coprocessor units. In some embodiments, multiple instances of processing unit 1050 may be coupled to interconnect 1060. Processing unit 1050 (or each processor within 1050) may include cache or other forms of onboard memory. In some embodiments, processing unit 1050 may be implemented as a general-purpose processing unit, while in other embodiments, it may be implemented as a special-purpose processing unit (e.g., ASIC). Generally, computing device 1010 is not limited to any particular type of processing unit or processor subsystem.

[0089] As used herein, the term "module" refers to a physical, non-transitory computer-readable medium that is configured to perform specified operations or stores information (e.g., program instructions) instructing other circuitry (e.g., a processor) to perform specified operations. Modules can be implemented in a variety of ways, including as hardwired circuitry or as memory storing program instructions executable by one or more processors to perform operations. Hardware circuitry may include, for example, custom-designed very large-scale integrated circuits (VLSI) or gate arrays, off-the-shelf semiconductors (e.g., logic chips), transistors, or other discrete components. Modules may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. A module can also be any suitable form of non-transitory computer-readable medium storing program instructions executable to perform specified operations.

[0090] Memory 1012 may be used by processing unit 1050 (e.g., storing instructions executable by processing unit 1050 and data used by processing unit 1050). Memory 1012 may be implemented by any suitable type of physical storage medium, including hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDRSDRAM, RDRAM, etc.), ROM (PROM, EEPROM, etc.), etc. In one embodiment, memory 1012 may consist only of volatile memory. Memory 1012 may store program instructions executable by computing device 1010 using processing unit 1050, including program instructions executable to enable computing device 1010 to implement the various techniques disclosed herein.

[0091] According to various embodiments, I / O interface 1030 may represent one or more interfaces and may be any of various types of interfaces configured to couple to and communicate with other devices. In one embodiment, I / O interface 1030 is a bridge chip from a front end to one or more back end buses. I / O interface 1030 may be coupled to one or more I / O devices 1040 via one or more corresponding buses or other interfaces. Examples of I / O devices include storage devices (hard disks, optical drives, removable flash drives, storage arrays, SANs, or associated controllers), network interface devices, user interface devices, or other devices (e.g., graphics, sound, etc.).

[0092] Various articles of manufacture are also envisioned that store instructions (and, optionally, data) executable by a computing system to implement the techniques disclosed herein. The computing system may use one or more processing elements to execute the instructions. Articles of manufacture include non-transitory computer-readable storage media. Contemplated non-transitory computer-readable storage media include portions of the storage subsystem of a computing device and storage media such as magnetic media (e.g., magnetic disks) or optical media (e.g., CDs, DVDs, and related technologies, ETC). Non-transitory computer-readable media can be volatile or non-volatile memory.

[0093] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of this disclosure, even though only a single embodiment has been described with respect to a particular feature. Unless otherwise stated, the examples of features provided in this disclosure are intended to be illustrative rather than restrictive. The above description is intended to cover such alternatives, modifications, and equivalents that will be apparent to those skilled in the art who benefit from this disclosure.

[0094] The scope of this disclosure includes any feature or combination of features disclosed herein (express or implicit), or any generalization thereof, whether or not it alleviates any or all the problems addressed herein. Therefore, during the examination of this application (or an application claiming priority thereto), new claims may be formulated for any such combination of features. In particular, with reference to the appended claims, features of dependent claims may be combined with features of independent claims, and features of individual independent claims may be combined in any suitable manner, not just the specific combinations listed in the appended claims.

Claims

1. A method for assessing trust between devices, comprising: Following a previous authentication step in the authentication process, a request is received at a first computing device to perform subsequent authentication steps in the authentication process to authenticate a user to the serving computer system, wherein the request includes first authentication information related to the previous authentication steps, and wherein the authentication process is initiated by a second computing device. as well as The first computing device determines whether to allow the subsequent authentication steps to be performed on the first computing device, wherein the determination includes: The trust factor between the first computing device and the second computing device is evaluated based on the first authentication information received by the first computing device and the second authentication information stored by the first computing device. Based on the assessed trust factors, the subsequent authentication steps are prohibited from being performed on the first computing device.

2. The method according to claim 1, further comprising: Based on the prohibition of the subsequent authentication steps, it was determined that the authentication process was associated with a man-in-the-middle attack.

3. The method according to claim 1, wherein, Assessing the trust factors between the first computing device and the second computing device includes: assessing the similarity between comparable data in the first authentication information and the second authentication information, wherein the comparable data includes at least one of the following: The Internet Protocol (IP) addresses corresponding to the first computing device and the second computing device; The geographical locations of the first computing device and the second computing device; Credential information for the first computing device and the second computing device; Cookies associated with the first computing device and the second computing device; or The challenge key associated with the first computing device and the second computing device.

4. The method according to claim 3, wherein, Assessing the trust factors includes: evaluating individual trust factors against at least two comparable data points, and determining the trust factors based on a combination of the individual trust factors.

5. The method according to claim 3, wherein, Determining whether to allow the subsequent authentication steps to be performed on the first computing device includes: Assess individual trust factors using at least two comparable data points; and When at least one individual trust factor fails to meet the specified threshold for that at least one individual trust factor, the subsequent authentication steps are prohibited from being performed on the first computing device.

6. The method according to claim 1, further comprising: In response to the assessed trust factor meeting a specified threshold, the subsequent authentication steps are allowed to be performed on the first computing device.

7. The method according to claim 6, wherein, The specified threshold is a value of a trust factor that is determined to correspond to the security trust level between the first computing device and the second computing device.

8. The method according to claim 1, further comprising: The first computing device sends an indication to the service computer system regarding whether to allow the subsequent authentication steps to be performed on the first computing device.

9. A non-transitory computer-readable medium storing instructions thereon, the instructions being executable by a computing device to perform operations, the operations including: Based on a previous authentication step in an authentication process initiated by an additional computing device, a request is received at the computing device to perform a subsequent authentication step in the authentication process to authenticate a user to the serving computer system, wherein the request includes first authentication information related to the previous authentication step. The computing device determines the trust factor between the computing device and the additional computing device based on the first authentication information received by the computing device and the second authentication information stored by the computing device. In response to the trust factor meeting a specified threshold, the subsequent authentication steps are allowed to be executed; as well as If the trust factor does not meet the specified threshold, the subsequent authentication steps are prohibited.

10. The non-transitory computer-readable medium according to claim 9, wherein, The trust factor is determined based on an evaluation of the matching between comparable data in the first authentication information and the second authentication information, wherein the comparable data includes at least one of the following: The IP addresses corresponding to the computing device and the additional computing device; The geographical locations of the computing device and the additional computing device; The credential information of the computing device and the additional computing device; Cookies associated with the computing device and the additional computing device; or The challenge key associated with the computing device and the additional computing device.

11. The non-transitory computer-readable medium according to claim 10, wherein, The matching is determined for each of at least two comparable data points, and the trust factor is determined based on a combination of the matchings determined for the at least two comparable data points.

12. The non-transitory computer-readable medium according to claim 10, wherein, Determining whether to allow the subsequent authentication steps to be performed on the computing device includes: Assess individual trust factors using at least two comparable data points; and The subsequent authentication steps are prohibited when at least one individual trust factor fails to meet the specified threshold for that at least one individual trust factor.

13. The non-transitory computer-readable medium according to claim 9, wherein, The subsequent authentication steps include: The request is for authentication information from the user; and The authentication information from the user is evaluated based on the second authentication information stored on the computing device.

14. The non-transitory computer-readable medium according to claim 9, further comprising: In response to prohibiting the execution of the subsequent authentication steps, an instruction to prohibit the subsequent authentication steps is sent to the service computer system.

15. The non-transitory computer-readable medium according to claim 9, further comprising: The computing device stores a trust factor between the computing device and the additional computing device, determined when the trust factor meets the specified threshold, wherein the trust factor is accessed by the computing device in response to receiving at least one additional request initiated by the additional computing device to perform the subsequent authentication steps of the authentication process.

16. A method for assessing trust between devices, comprising: The service computer system receives the initial authentication steps of the authentication process from the first client computing device, which is used to authenticate the user to the service computer system; The service computer system sends a request for a secondary authentication step to a second client computing device, wherein the second client computing device is associated with the user, and wherein the request includes first authentication information related to the initial authentication step of the first client computing device; The service computer system receives an indication from the second client computing device regarding the following situation: the second client computing device has determined, in response to the request, that the trust factor between the second client computing device and the first client computing device cannot meet a specified threshold, wherein the trust factor is determined by the second client computing device based on the first authentication information and the second authentication information stored by the second client computing device; as well as Based on the instruction, the service computer system denies the first client computing device access to the service computer system through the authentication process.

17. The method of claim 16, further comprising: The service computer system provides a transfer attention notification to the first client computing device based on the instruction received from the second client computing device.

18. The method according to claim 17, wherein, The attention shift notification includes a notification regarding the pending authentication process, and the attention shift notification is removed after a specified period of time.

19. The method of claim 16, further comprising: The service computer system initiates a security notification corresponding to the first client computing device based on the instruction received from the second client computing device.

20. The method of claim 16, wherein, The instruction received from the second client computing device is an instruction from the first client computing device to perform a man-in-the-middle attack on the service computer system.

Images