Methods and systems for detecting unauthorized access

Abstract

Methods and systems for identifying unauthorized attempts to access an account on a computer system having authorized users are described. The methods and systems include determining that a count of failed attempts to access the account exceeds a maximum value. Based on the count exceeding the maximum value, one or more peer contacts associated with the authorized user are retrieved from stored user data. A failed attribution request is sent to the one or more peer contacts, and a response from at least one of the one or more peer contacts is received. If the response denies that the failed attempt was caused by an authorized user, a security action is taken regarding the account. The method may include first confirming that the number of failed attribution requests has not yet exceeded an abuse threshold to prevent a denial-of-service attack.

Description

Technical Field

[0001] This application generally relates to computer security, and more particularly to the detection of unauthorized access to accounts. Background Technology

[0002] In computing systems, security is typically maintained by requiring user credentials to accompany access requests. These credentials are compared to stored authorized user credentials, and if the verification is successful, the user's access request is considered authenticated and access is authorized.

[0003] A brute-force attack to gain unauthorized access to a user account may involve a series of failed authentication attempts. To limit this attack vector, systems sometimes restrict the number of failed attempts within a given timeframe. However, this facilitates denial-of-service attacks by blocking access to legitimate users. Furthermore, in some cases, these attempts may be legitimate attempts by an authorized user, but the user has misspelled their credentials or misremembered their password. It would be advantageous for a system to differentiate between failed authentication attempts by legitimate users and unauthorized authentication attempts from individuals other than authorized users. While these failed attempts are logged, they are more often invisible or ignored by the user. Some systems will prompt users about the legitimacy of new logins from new hosts, but if the account has been compromised, these alerts may be deleted before the legitimate user can see them. Attached Figure Description

[0004] Reference will now be made to the accompanying drawings, which illustrate exemplary embodiments of this application, wherein:

[0005] Figure 1 The illustration shows an example system including an authenticator for managing user authentication to a security system;

[0006] Figure 2 A sample method for identifying unauthorized attempts to access an account on a computer system is illustrated in flowchart form; and

[0007] Figure 3 Another example method for identifying unauthorized attempts to access an account on a computer system is illustrated in the form of a flowchart.

[0008] Similar reference numerals may be used in different diagrams to represent similar components. Detailed Implementation

[0009] In a first aspect, this application describes a method for identifying unauthorized attempts to access an account in a computer system, the account having authorized users. The method may include: determining that a count of failed attempts to access the account exceeds a maximum value; retrieving one or more peer contacts associated with the authorized user from stored user data based on the count exceeding the maximum value; transmitting a failure attribution request to the one or more peer contacts; receiving a response from at least one of the one or more peer contacts; and taking security actions regarding the account when the response denies that the authorized user caused the failed attempts.

[0010] On the other hand, this application describes a system for identifying unauthorized attempts to access an account in a computer system, the account having authorized users. The system includes: a processor; a memory storing user data, including one or more peer contacts associated with the authorized user; and an authentication application containing processor-executable instructions that, when executed by the processor, cause the processor to: determine that a count of failed attempts to access the account exceeds a maximum value; based on the count exceeding the maximum value, retrieve one or more peer contacts associated with the authorized user from the memory; transmit a failure attribution request to the one or more peer contacts; receive a response from at least one of the one or more peer contacts; and when the response denies that the authorized user caused the failed attempt, take a security action regarding the account.

[0011] In some implementations, the received credentials included in the access request are compared with the stored user credentials to find a mismatch, and the association count of the failed attempts is incremented.

[0012] In some implementations, the stored user data includes a peer list containing one or more peer contacts associated with an authorized user. In some cases, this list is stored in association with the account. In some cases, each peer contact in the peer list includes peer contact information to which a failed attribution request will be forwarded.

[0013] In some implementations, security actions include at least one of the following: sending a notification to a security administrator, changing authorization settings for the account, temporarily blocking further access attempts to the account, or imposing a further level of authentication required to access the account after successful authentication.

[0014] In some implementations, the method and system may further include sending an attribution request to a user contact address for an authorized user, receiving a response from the user contact address, and taking security actions when the response denies the user's participation in the failed attempt.

[0015] In some implementations, one or more peer contacts include multiple peer contacts in hierarchical order, and transmission includes sending a failure attribution request to the first peer contact in the hierarchical order; waiting for a response; and if the response is not received within a time window, sending a failure request to the next peer contact in the hierarchical order. In some cases, the method and system may include temporarily blocking further access attempts to the account while waiting for a response. In some cases, waiting and sending for each consecutive peer contact in the hierarchical order is repeated until a response is received or the time window for the last peer contact expires.

[0016] In some implementations, the transmission failure attribution request includes determining that the number of transmission failure attribution requests within a time period is below an abuse threshold as a prerequisite for transmission attribution requests.

[0017] Other aspects and features of this application will be understood by those skilled in the art by reading the following illustrative description in conjunction with the accompanying drawings.

[0018] In this application, the terms “about,” “approximately,” and “substantially” are intended to cover variations that may exist within the upper and lower limits of a range of values, such as variations in properties, parameters, and dimensions. In non-limiting examples, the terms “about,” “approximately,” and “substantially” may mean an increase or decrease of 10% or less.

[0019] In this application, the term "and / or" is intended to cover all possible combinations and sub-combinations of the listed elements, including any single element, any sub-combination, or all elements listed, and does not necessarily exclude additional elements.

[0020] In this application, the phrase “...or at least one of ...” is intended to cover any one or more of the listed elements, including any single element, any sub-combination, or all of the listed elements, without excluding any additional elements, and not necessarily requiring all elements.

[0021] This article serves as a reference for attempts to access an “account.” The term “account” will be given a broad interpretation and is not limited to a specific type of account. It means any resource whose access can be restricted by a user authentication request. Examples could include attempting to unlock a locked device such as a mobile phone or personal computer, attempting to access a user account in a computer environment such as a corporate network or social network, or attempting to access a service such as a video streaming service. In this sense, an “account” refers to any computer security resource that has restricted access to a user presenting valid authentication credentials.

[0022] In computing devices and network environments, authentication is a cornerstone security technology. Authentication involves receiving some input to prove the identity of a user requesting access to a resource. The most typical example of user authentication data is a username and password. Other examples may include biometric input, a separate password without a username (although it can be associated with a username), answers to challenge phrases, etc. The authenticator verifies the validity of the provided user authentication data by comparing it to stored user data. User data may include profiles for multiple users, each with a unique username and password. User data may include additional data, such as authorization data indicating the access levels available to the user.

[0023] A key security challenge for computing systems is preventing repeated attempts to access accounts. One technique is to limit the number of consecutive failed attempts and lock the account if too many attempts fail. This is frustrating for legitimate users who might misspell their passwords, forget that Caps Lock is on, misremember their passwords, or try many of their more commonly used passwords to try and guess which password they used for the account. Furthermore, locking an account after a maximum number of failed attempts creates a denial-of-service risk. This can be addressed by limiting the account lockout time to a short period, but this allows for continued attacks, albeit at a slower pace. Other techniques may attempt to use behavioral analysis, IP address information, or other side information to assess the nature of failed access attempts and distinguish between legitimate and malicious attempts.

[0024] When a user successfully logs into their account (i.e., authentication is successful), the system can apply two-factor authentication (2FA) as a technique to enhance system security. 2FA simply applies a second authentication step after the initial successful authentication. This can be done by presenting further user credentials requests at the same user interface, or by providing some data (e.g., code) via an alternative user account for the same user, requesting the user to access that alternative user account, and presenting that data to further authenticate the user's identity. If user credentials for both accounts are compromised, a malicious actor could potentially bypass the 2FA process. Strong 2FA requires one element to be something only the user knows and possesses, such as a unique rotary token or a secondary device similar to a mobile phone to confirm the secondary approval prompt.

[0025] 2FA adds an additional security layer to user authentication, but it does not address the issue of authentication failures, nor does it address the need to assess whether a failed authentication represents an attack on the system or an attempt by a legitimate user to access their account.

[0026] According to one aspect of this application, the computing system determines how to handle authentication failures by obtaining attribution information. In one instance, a user can be contacted via a separate communication channel (such as through a different account or a different device) to request information about one or more failed attempts to access the account. Through the separate communication channel, the user can confirm or deny that the failed attempts are attributable to the user. If the response to the request is negative attribution, the system can take certain security actions because the failed attempts represent a potential attack.

[0027] According to another aspect of this application, as an alternative or supplement to the user-requested information, attribution information can be solicited from one or more peers associated with the user. That is, the system may already have stored information associated with the user, linking the user to one or more peers. One or more peers may send attribution requests at devices or points of contact specified for one or more peers. A response from one of the peers may indicate that the failed authentication attempt(s) is attributable to the user, and the system may treat this response as a confirmation that the failed authentication attempt(s) was a legitimate user's failed verification. This determination may mean that any alarms or lockout conditions can be cleared. A response from a peer indicating that the failed authentication attempt(s) is not from the user may trigger a security action. In some instances, even if the user has indicated that the failed attempt(s) is legitimate, an indication from a peer not attributable to the user may result in a security action.

[0028] First refer to Figure 1 The illustration schematically depicts an example system 100 for detecting potential attacks on user authentication. System 100 includes a security system 102. Security system 102 represents a resource that one or more users seek to access. In some cases, security system 102 may include a corporate network environment with all its internal resources. In other examples, it may be a social network, a gaming network, a financial network, or any other type of computing resource. Security system 102 may be operatively connected to multiple networks, which may include public networks, private networks, or both.

[0029] Authenticator 104 manages the authentication of user requests to access security system 102. Authenticator 104 may include or has access to stored user data 106. Authentication requests provide user authentication data to authenticator 104, which then evaluates the validity of the user authentication data by comparing it to the stored user data 106. For example, the stored user data 106 may include identification data for multiple authorized users, including usernames (or user IDs), associated passwords, and any associated security settings, such as authorization levels.

[0030] In this example system 100, user data 106 includes a record of failed authentication attempts for each user, which may include a count of failed authentication attempts 108. These attempts may include all unsuccessful attempts to access an account associated with a particular user. In some cases, the count may be a count of consecutive failed attempts without successful authentication. In some cases, the count may be time-limited to attempts over the past hour, day, week, or some other time period. In yet another case, the count may include discontinuous attempts over a period of time. The record of failed authentication attempts may include additional metadata about the attempts, such as IP addresses or other identifying information about the source of the attempts.

[0031] In this example, system 100 further includes a peer list 110 stored within user data 106, associated with authorized users. The peer list 110 contains identifiers for one or more peers assigned to an authorized user. This assignment can be made by the authorized user when configuring his or her account as part of the setup process. In some cases, such as corporate environments, peer assignment can be policy-based and at least partially controlled by the administrator. For example, an authorized user can be required to include his or her direct supervisor as a peer.

[0032] Peer list 110 may include a user identifier for each peer in the peer list, such as a username or user ID. Authenticator 104 may access peer list 110 to obtain user identifiers for each peer. Peer list 110 may include contact information for each peer. In some implementations, Authenticator 104 may search for user data 106 for contact details for each peer based on the user identifiers in peer list 110. Contact details may include mobile numbers, email addresses, messaging identities, social network identifiers, SIP URIs, or other peer contact data to which Authenticator 104 may send notifications or requests. In some implementations, peer list 110 may include a status indicating whether a peer is available. It is understood that peer contacts are distinct and separate individuals associated with a user account. Peer contact information includes one or more addresses or accounts associated with (owned or operated by) a peer contact. It may include device identifiers or other data specific to devices or accounts controlled by the peer contact that represent contact information identifying the peer contact. For clarity, peer contact information is not alternative account or contact information for a user.

[0033] In an open system, peers may not necessarily be authorized users of security system 102, and their details may not be stored in user data 106 as user storage for security system 102. However, authorized users may have designated them as peers in the configuration of user accounts, and may have provided peer contact data, which is subsequently stored in or associated with peer list 110.

[0034] Although illustrated as a single database, user data 106 can be implemented as two or more data storage elements comprising the database, and may contain multiple records, wherein at least one of the records stores user authentication information for the user, and wherein at least another record stores a peer list 110 associated with the user.

[0035] As described above, authenticator 104 can track failed authentication attempts associated with a user account. If the number of failed authentication attempts exceeds a maximum value, authenticator 104 can output a home request. A trigger for a home request can be that the count of failed authentication attempts for the user account exceeds a preset threshold, such as five or ten. In some implementations, the trigger can be based on consecutive failed authentication attempts without successful authentication. The trigger can also consider the time when the failure occurred, such that the threshold is based on the maximum number of failed authentication attempts within a certain time window (e.g., 15 minutes, one hour, one day, etc.). Some implementations may consider the number of failed attempts from a given source IP address without success, or a lower threshold if the source IP is not the most recent source of a positive authentication. Other factors can be included in determining whether to send a home request.

[0036] Once authenticator 104 determines that an attribution request will be sent, it sends a message to the user, one or more peers, or both. The message can be sent via any suitable medium, including instant messaging, SMS, email, or other communication types. The message informs the user and / or peer of the maximum number of failed attempts to access the user's account and requests the recipient to indicate whether the attempt was made by the user. Depending on the implementation, the message may include selectable icons, buttons, or other response elements to trigger a response message. In some cases, the message may include two distinct selectable response elements: one attributing the failure to the user, and another attributing the failure to someone other than the user. In some cases, the message may include a link that, when selected, opens a browser session and links to a webpage that provides the attribution response. Other mechanisms for soliciting and obtaining electronic feedback from users and / or peers can be understood.

[0037] In some cases, the message may contain information about failed authentication attempts. This information may be obtained by the authenticator 104 from stored records of failed authentication attempts for that user account. The information in the message may include information identifying the user account and user, the time and / or date of each attempt, the geographic location from which the access attempt appears to have originated (e.g., based on IP address), and / or the count of failed attempts.

[0038] Although authenticator 104 is shown as separate from security system 102 for ease of discussion, it will be understood that authenticator 104 can be implemented as part of security system 102. It will also be understood that authenticator 104 can be implemented as software operating on a suitable computing platform, such as a server or similar networked computing system. This software is executed by one or more processors within the computing system to enable the computing system to perform the operations described for authenticator 104. Any suitable programming language and / or program structure can be used to implement the software-implemented authenticator 104.

[0039] Security system 102 is shown as residing in the "cloud" of a networked environment. In some cases, security system 102 may be partially or wholly located local to a user equipment with a network connection to the cloud. Authenticator 104 may be partially implemented locally on the user equipment to protect security system 102 and partially implemented in the cloud to perform user authentication on input user credentials and authorize access by providing access tokens, etc., to the user equipment. Other architectures for security system 102 will be understood by those skilled in the art.

[0040] Now for reference Figure 2 The flowchart illustrates an example method 200 for identifying unauthorized attempts to access an account on a computer system. Method 200 may be implemented by authenticator 104.

[0041] In operation 202, an access attempt is made to the user account. This may involve a login attempt via a website, mobile application, lock screen, or other software security checkpoint. In some implementations, the access attempt includes receiving user credentials, such as username and password. In some cases, the access attempt may involve the exchange of multiple messages between the remote computing device and the authenticator. The user credentials are evaluated in operation 204 to determine their validity. For example, this may include querying a user database storing username and password combinations. As those skilled in the art will understand, appropriate encryption and hashing algorithms can be used to protect the database. If the user credentials are determined to be valid in operation 204, the requester is granted access 206. This may include providing the remote device with a security token or data, enabling it to access further parts of the secure system. It may include establishing a secure connection or session between the remote device and the secure system. Other mechanisms used to enable access to the secure system will be understood.

[0042] If the user credentials are determined to be invalid in operation 204, then in operation 208 it is determined whether the failed authentication attempts resulted in exceeding a threshold number of failures associated with the user account. At this point, it will be understood that access attempts are associated with a given user account. For implementations in lower-risk environments, the threshold can be set to a larger number than the threshold for medium-risk environments. For higher risk, the threshold can be set low, or set to 1 (a) to alert the peer on each failed attempt. If the access attempt involves failures to identify an existing user account, such as due to providing an incorrect username that does not have an associated account, then the failed attempts need not be counted based on any user account. It will also be understood that the threshold can take into account several factors, including the time window in which the failed attempt occurred, whether any intermediate successful attempts were made, and other factors as described above.

[0043] If it is determined in operation 208 that the count of failed authentication attempts does not exceed a threshold, method 200 returns to operation 202. If the count exceeds the threshold, attribution information can be sought to identify the source of the unauthentication attempts. In operation 210, user contact information associated with the user account is retrieved. This may include email addresses, mobile numbers, message IDs, or other user contact data stored in association with the user account. In operation 212, peer contact information for one or more peers associated with the user account is retrieved. This may include obtaining peer contact information from a peer list stored with peers associated with the user account. Peer contact information may include email addresses, mobile numbers, message IDs, or other peer contact information to which the system can send messages or notifications.

[0044] In operation 214, a notification is sent to the user and peer. For a given implementation, the notification can be sent via any suitable communication medium, such as SMS, email, social network messages, instant messaging, or others. The notification is addressed based on the contact information obtained in operations 210 and 212. The notification to the user may differ from the notification to the peer. The notification may contain a link to a website or other interface through which the recipient can provide a response. The desired response is whether the failed attempt can be attributed to the user. Within itself, operation 214 can be exploited by an attacker who makes multiple failed authentication attempts on a large number of authorized users, triggering a large number of peer confirmation requests. Thus, some implementations will establish a counter mechanism, operation 217, to count the peer confirmation requests in a given time frame and suppress the requests, as well as trigger appropriate security actions in operation 225. If the count falls below an acceptable threshold (which may be labeled the "abuse threshold"), the process continues to operation 216. It should be understood that operation 217 can occur before operation 214 as a prerequisite for transmitting the notification.

[0045] In this example, the system first waits for a response from the user, as indicated in operation 216. If the response received from the user is negative, indicating the attempt was made by the user, the system can take a security action in operation 218. If the response is positive, indicating the attempt was legitimate by the user, the system continues to evaluate at least one peer response. In some implementations where it can be determined that no direct peer is available for the response, and depending on the applied security risk level and management policy, the system can trigger an appropriate security action. In one embodiment of this disclosure, the security action performed in operation 225 differs from the security action performed in operation 218. More precisely, in one embodiment of this disclosure, from a security perspective, the security action performed in operation 218 is more stringent than the security action performed in operation 225. In a variant, the security action performed in operation 225 is the same as the security action performed in operation 218.

[0046] In operation 220, the system evaluates the peer response. If the failed peer confirmation attempt can be attributed to the user, the system returns to 202 and takes no security action. In some cases, the system may clear restricted security settings regarding a user account. In one example, the system may reset the number of failed attempts stored in a counter to zero, allowing the user to retry accessing the account without immediately re-triggering the attribution process.

[0047] If the peer response in operation 220 denies user ownership, then the system takes a security action in operation 222.

[0048] Security actions may include sending notifications to administrators or other security points. It may include changing authorization data for a user account to provide more restricted access in the event of successful authentication. In some cases, it may include locking the account for a preset period to prevent successful authentication. In some cases, this may lead to additional security oversight, such as logging or more robust logging of all activity associated with the user account and any attempts to access the user account. In some cases, security actions may include imposing a further level of authentication even if someone is able to authenticate successfully.

[0049] In some cases, peer notifications can be based on a peer hierarchy. In one exemplary implementation, the attribution process does not involve contacting the user for attribution information, but only involves contacting one or more peers associated with the user's account. Figure 3 Another example method 300 for identifying unauthorized attempts to access an account on a computer system is shown. In this example, the authenticator monitors access attempts and determines when the number of consecutive failed access attempts exceeds a threshold, as indicated by operations 302, 304, 306, and 308.

[0050] Once the number of consecutive failed authentication attempts exceeds a threshold, peer contact information is retrieved from storage in Operation 310. Peer contact information may include a peer list, which may be ordered sequentially. In some cases, management policies may determine the order. For example, a direct supervisor may be ranked first. IT department representatives may be included in the ranking. Colleagues may have a lower rank than IT department personnel or supervisors.

[0051] In operation 312, a notification regarding a failed authentication attempt is sent to the first or highest-ranking peer associated with the user account. This notification requests attribution for the failed authentication attempt. Specifically, it may request confirmation that the failed authentication attempt was a user's failed attempt. The system then awaits a response, as indicated in operations 314 and 316. The response time can be set to any suitable time for a particular implementation. For example, a number of minutes (1, 2, 5, etc.) can be set as the response time. If the request for a response does not result in the receipt of an attribution response from the peer, the system may return to operation 312 to send the notification to the next peer in hierarchical order, as shown in operation 322. Within itself, operation 312 can be exploited by an attacker who performs multiple failed authentication attempts on a wide range of authorized users, triggering a large number of peer verification requests. Thus, some implementations will establish counter measures, operation 313, to count peer confirmation requests in a given time frame and suppress the requests, and trigger appropriate security actions in operation 315. If the count falls below the abuse threshold, the process will continue to operation 314. It should be understood that operation 313 may occur before operation 312 and as a prerequisite for sending the attribution request in operation 312.

[0052] If a response is received in operation 318, the response confirms that the user is the source of the failed attempt. In this case, method 300 returns to operation 302 to accept a new attempt to access the account, or the response denies user participation. In this case, a security action regarding the account is taken, as shown in operation 320. As described above, the security action may include one or more operations such as notification, locking, restriction, or otherwise taking action regarding the account. In one embodiment of this disclosure, the security action performed in operation 315 is different from the security action performed in operation 320. More precisely, in one embodiment of this disclosure, the security action performed in operation 320 is more stringent than the security action performed in operation 315. In a variant, the security action performed in operation 315 and the security action performed in operation 320 are the same.

[0053] In some cases, security actions can be taken to prevent further attempts to access a user account while awaiting a response from a peer contact. That is, the account can be temporarily locked while awaiting attribution information from the peer contact. This can help slow down an attack if the failed authentication attempt is part of it. Confirmation of user engagement in Operation 318 can lead to the removal of account restrictions. Conversely, a peer contact response that denies user engagement can lead to leaving the account restrictions in place as a security action in Operation 322. Further actions can be taken, such as notifying the IT administrator about the locked account.

[0054] If the peer contact list is exhausted without a response from any peer contact within the timeout period, and / or if no peer is determined to be active and / or available, the system may be configured to: notify one or more IT administrators to remove security restrictions, search for user confirmation at alternative user contact addresses, or take one or more other actions. In some examples, the account may remain locked until at least one peer contact responds to the notification or the security administrator clears the event on sufficient alternative authentication.

[0055] The exemplary embodiments of this application are not limited to any particular operating system, system architecture, mobile device architecture, server architecture, or computer programming language.

[0056] It should be understood that applications, modules, routines, processes, threads, or other software components that implement the described methods / processes can be implemented using standard computer programming techniques and languages. This application is not limited to specific processors, computer languages, computer programming specifications, data structures, or other such implementation details. Those skilled in the art will recognize that the described processes can be implemented as portions of computer-executable code stored in volatile or non-volatile memory, portions of application-specific integrated circuits (ASICs), etc.

[0057] Certain modifications and alterations may be made to the described embodiments. Therefore, the above embodiments are considered illustrative rather than restrictive.

Claims

1. A method for identifying unauthorized attempts to access an account in a computer system, the account having authorized users, the method comprising: It was determined that the count of failed attempts to access the account exceeded the maximum value; Based on the count exceeding the maximum value, retrieve one or more peer contacts associated with the authorized user from the stored user data; Send a failure attribution request to the one or more peer contacts, the failure attribution request requesting confirmation that the failure attempt was a user's failure attempt; Receive a response from at least one of the one or more peer contacts; When the response denies the authorized user, resulting in the failed attempt, take security actions regarding the account, and When the response confirms that the authorized user caused the failed attempt to access the account, the count of the failed attempts to access the account is cleared.

2. The method of claim 1, wherein the determination comprises: Receive a request for access to the account, containing the provided credentials; Determining that the provided credentials do not match the user credentials stored for the account; and Increment the count of the failed attempts.

3. The method of claim 1, wherein the stored user data includes a peer list containing one or more peer contacts associated with the authorized user.

4. The method of claim 3, wherein the peer list is stored in association with the account.

5. The method of claim 3 or 4, wherein each peer contact in the peer list comprises: The information of the peer contact to whom the failure attribution request is to be sent.

6. The method according to any one of claims 1 to 4, wherein the security action includes at least one of: sending a notification to a security administrator to change the authorization settings for the account, temporarily blocking further access attempts to the account, or, after successful authentication, imposing a further level of authentication required to access the account.

7. The method according to any one of claims 1 to 4, wherein the method further comprises: The attribution request is sent to the user contact address of the authorized user, a response is received from the user contact address, and the security action is taken when the response denies the user's participation in the failed attempt.

8. The method according to any one of claims 1 to 4, wherein the one or more peer contacts comprise a plurality of peer contacts in hierarchical order, and wherein the transmission includes: The failed attribution request is sent to the first peer contact in the hierarchical order. Waiting for the response; as well as If the response is not received within the time window, the failure attribution request is sent to the next peer contact in the hierarchy.

9. The method of claim 8, wherein the method further comprises: While awaiting the response, temporarily block further access attempts to the account.

10. The method of claim 8, wherein the waiting and sending are repeated for each consecutive peer in the hierarchical order until the response is received or the time window for the last peer expires.

11. The method according to any one of claims 1 to 4, wherein transmitting the failure attribution request comprises: The condition for transmitting the failed attribution requests is determined to be that the number of failed attribution requests transmitted within a time period is lower than the abuse threshold.

12. A system for identifying unauthorized attempts to access an account in a computer system, the account having an authorized user, the system comprising: processor; A storage device for storing user data, the user data including one or more peer contacts associated with the authorized user; as well as The authentication application includes processor-executable instructions that, when executed by the processor, cause the processor to: It was determined that the count of failed attempts to access the account exceeded the maximum value; Based on the count exceeding the maximum value, retrieve one or more peer contacts associated with the authorized user from the memory; Send a failure attribution request to the one or more peer contacts, the failure attribution request requesting confirmation that the failure attempt was a user's failure attempt; Receive a response from at least one of the one or more peer contacts; as well as When the response denies the authorized user, resulting in a failed attempt, take security actions regarding the account, and When the response confirms that the authorized user caused the failed attempt to access the account, the count of the failed attempts to access the account is cleared.

13. The system of claim 12, wherein the instructions cause the processor to determine that the count of failed attempts to access the account exceeds the maximum value by: Receive a request for access to the account, containing the provided credentials; Determining that the provided credentials do not match the user credentials stored for the account; and Increment the count of the failed attempts.

14. The system of claim 12, wherein the stored user data includes a peer list containing one or more peer contacts associated with the authorized user.

15. The system of claim 14, wherein the peer list is stored in association with the account.

16. The system of claim 14 or 15, wherein each peer contact in the peer list comprises: The information of the peer contact to whom the failure attribution request is to be sent.

17. The system according to any one of claims 12 to 15, wherein the security action includes at least one of: sending a notification to a security administrator to change the authorization settings for the account, temporarily blocking further access attempts to the account, or, after successful authentication, imposing a further level of authentication required to access the account.

18. The system according to any one of claims 12 to 15, wherein the instructions further cause the processor to: transmit an attribution request to a user contact address for the authorized user, receive a response from the user contact address, and take the security action when the response denies the user's participation in the failed attempt.

19. The system according to any one of claims 12 to 15, wherein the one or more peer contacts comprise a plurality of peer contacts in hierarchical order, and wherein the instructions cause the processing to be transmitted by: The failed attribution request is sent to the first peer contact in the hierarchical order. Waiting for the response; and If the response is not received within the time window, the failure attribution request is sent to the next peer contact in the hierarchy.

20. The system of claim 19, wherein the instructions further cause the processor to: temporarily block further access attempts to the account while waiting for the response.

21. The system of claim 19, wherein the waiting and the sending are repeated for each consecutive peer in the hierarchical sequence until the response is received or the time window for the last peer expires.

22. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor of a computer system, cause the processor to identify an unauthorized attempt to access an account having an authorized user, the instructions, when executed by the processor, cause the processor to: It was determined that the count of failed attempts to access the account exceeded the maximum value; Based on the count exceeding the maximum value, retrieve one or more peer contacts associated with the authorized user from the stored user data; Send a failure attribution request to the one or more peer contacts, the failure attribution request requesting confirmation that the failure attempt was a user's failure attempt; Receive a response from at least one of the one or more peer contacts; When the response denies the authorized user, resulting in the failed attempt, take security actions regarding the account, and When the response confirms that the authorized user caused the failed attempt to access the account, the count of the failed attempts to access the account is cleared.

Images