[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2019032300A1 - Système et procédés de prévention active d'attaques par force brute - Google Patents

Système et procédés de prévention active d'attaques par force brute Download PDF

Info

Publication number
WO2019032300A1
WO2019032300A1 PCT/US2018/043834 US2018043834W WO2019032300A1 WO 2019032300 A1 WO2019032300 A1 WO 2019032300A1 US 2018043834 W US2018043834 W US 2018043834W WO 2019032300 A1 WO2019032300 A1 WO 2019032300A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
brute force
iterable
parameter
force protection
Prior art date
Application number
PCT/US2018/043834
Other languages
English (en)
Inventor
Navneet Kumar
Vikas CHOURASIVA
Original Assignee
Blue Jeans Network, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/788,635 external-priority patent/US10362055B2/en
Application filed by Blue Jeans Network, Inc. filed Critical Blue Jeans Network, Inc.
Publication of WO2019032300A1 publication Critical patent/WO2019032300A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Definitions

  • the present invention is directed to providing techniques and systems for protecting a computing system from brute force attacks without requiring a Turing challenge.
  • Cloud-based computing systems are increasingly at risk of security breaches from brute force and other types of attacks designed to gain privileged access to the system.
  • a brute force attack single client devices, or groups of client devices, are configured to repeatedly request access to the cloud-based system until access is granted. Each request may iterate through a sequence of possible values for login parameters such as user names and passwords. Because the total number of possible values is typically much larger than the number of registered or correct values for logging in to the system, brute force attacks typically involve a large number of incorrect requests for access before they succeed.
  • Turing challenges such as CAPTCHAs require a human user at the client device to answer a question or provide information in response to an inquiry, puzzle, or problem that is designed to be easy for a human but difficult for a computer program to provide a correct response.
  • client devices that correctly provide a response to the Turing challenge will have their request for access (e.g., a request containing login information) processed, and an automated brute force attack will not be able to submit any of its requests for access.
  • having to respond to a Turing challenge with every login can be irritating to human users.
  • approaches for protecting against brute force attacks while avoiding annoying human users with a Turing challenge. Such alternative systems and methods for protecting against brute force attacks are described herein.
  • a brute force protection system is configured to receive a collection of request metadata associated with a current request from a middleware device, wherein the request metadata include a plurality of iterable parameter values. These iterable parameter values may be values for passcodes, meeting identifiers, user identifiers, content management system identifiers, and the like.
  • the system may create one or more request signatures for the current request by replacing the plurality of iterable parameter values associated with the current request with respective placeholders.
  • a representation of the collection of request metadata (or a subset of the collection) and a representation of the one or more request signatures may be saved in a database.
  • the system may also determine one or more counts for the one or more request signatures based on the number of identical request signatures presented to the system or saved in the database. If any of the counts of identical request signatures is greater than a maximum attempt threshold, the request will be determined to be a potential brute force attack request, and an appropriate responsive action will be determined, such as delaying processing of additional requests having the same signature based on the number of received requests with that signature. Such an action and all or some of the request metadata may also be provided to the middleware device. In certain embodiments, the system operates without providing a Turing challenge to client devices.
  • FIG. 1 depicts an exemplary distributed computing system in accordance with some embodiments of the invention
  • FIG. 2 depicts an exemplary sequence of requests in accordance with some embodiments of the invention
  • FIG. 3 shows a flow chart for an exemplary process concerning providing brute force protection in accordance with some embodiments of the invention
  • FIG. 4 shows a flow chart for an exemplary process concerning providing brute force protection in accordance with some embodiments of the invention
  • FIG. 5 shows a block diagram of an exemplary computing system in accordance with some embodiments of the invention.
  • Embodiments of apparatuses, computer systems, computer readable mediums, and methods for protecting against brute force attacks are described herein.
  • the approaches described here do not require a Turing challenge, and accordingly can operate instead of a Turing challenge.
  • Human users may be annoyed by having to interact with a Turing challenge, and some users may find the Turing challenge to be too difficult.
  • Turing challenge will cause the login process to take more time than it would without the challenge, which may further annoy human users.
  • a brute force attack may be sophisticated enough to pass a Turing challenge.
  • the approaches described below may be used in addition to a Turing challenge for additional security.
  • Embodiments described herein operate by identifying certain sequences of erroneous requests as likely to be part of brute force attacks, and responding appropriately.
  • FIG. 1 depicts an exemplary distributed computing system 100 in accordance with some embodiments of the invention.
  • System 100 is configured with components of a video conferencing service, but in certain embodiments, other types of computing systems involving remote access would also be compatible with the described approaches.
  • System 100 includes a brute force protection system 102 comprising one or more devices including a database 104 and an application 106 that implements the logic of the brute force protection system.
  • System 100 includes a middleware server 108 that is configured to allow remote requests for access over a network 110.
  • Middleware server 108 may provide any computer- based service to client devices, such as providing aspects of a video conferencing service (e.g., receiving, compositing, and providing video streams for video conferencing endpoints).
  • Network 110 may be the internet, a local area network, a wide area network, a telecommunications network, or the like.
  • Brute force protection system 102 is in communication with the middleware server 108.
  • brute force protection system 102 may be local to the middleware server 108, for example via an internal network such as a local area network, and in other embodiments, they are in communication via network 110, where network 110 is not a local area network.
  • Middleware server 108 is configured to receive connection requests over network 110 from various remote client devices 114, such as room conference system 114a and laptop 114b (associated, in this example, with video conferencing endpoint 112a), and tablet device 114c, associated with endpoint 112b.
  • Client devices 114 may be associated with human users 116 (e.g., User A 116a and User B 116b). In certain circumstances, a client device may actually be a malicious bot 118, where such a bot is configured to attempt to gain access to middleware server 108 by way of a sequence of automated connection requests (e.g., a brute force attack).
  • a malicious bot 118 where such a bot is configured to attempt to gain access to middleware server 108 by way of a sequence of automated connection requests (e.g., a brute force attack).
  • client devices 114 associated with endpoints 112 in a particular video conference will each provide a request to the middleware server 108 to join the video conference (i.e., a request for access), and as part of successfully joining the video conference, the client devices 114 will be associated with endpoints 112 in the conference.
  • the request will contain values for one or more iterable parameters used to identify or authenticate the associated user 116 (e.g., user ID, passcode) and/or the requested item (e.g., video conference meeting ID, content management system ID, passcode).
  • An iterable parameter value (i.e., the value corresponding to the iterable parameter) is a string of characters provided by a client as part of enabling access to or identifying a resource, such as a video conference, an account, a media stream, or a file.
  • a resource such as a video conference, an account, a media stream, or a file.
  • Some examples of iterable parameters and their values are: (meeting_id, 900900), (meeting_passcode, 9000), (user_id, 454), (user_password, mysecret), (content id, 1234), and (content token, abed).
  • a brute force attack involves repeatedly requesting access to a middleware service or login by formulating and submitting a lengthy sequence of requests that includes values for one or more iterable parameters, where the characters comprising the iterable parameter value(s) are varied with each subsequent request, until access to the middleware is granted.
  • a human user may provide an erroneous iterable parameter value via a client device, but if the human user knows or is possession of the correct values, such typographical or other errors will typically be corrected after a small number of follow-on access attempts.
  • Requests may be, for example, for the purpose of authenticating a user (e.g., associated with an authentication operation), or for joining a session, such as a video conferencing session,
  • FIG. 2 depicts a toy example showing how a sequence of requests 200 might be handled by certain embodiments of system 100 including a brute force protection system 102, where some requests are initiated by a human user 116, and others are initiated by a malicious bot 118.
  • Request 1 the human user submits a request via a client device 114 for access to middleware 108.
  • Request 1 contains a typographical error in an iterable parameter value, such as a mistyped passcode.
  • the middleware begins to process Request 1, but the resulting Response 1 status is an error code (e.g., "401 unauthorized").
  • Errors in an iterable parameter value should result in an erroneous response status, such as a response status in the 400 series (e.g., 401 unauthorized, 403 forbidden, 404 not found, and the like). Because the Response 1 status resulted in an error, the middleware provides Request 1 to a brute force protection system 102 for evaluation to predict whether Request 1 is likely to be part of a brute force attack.
  • Request 1, Response 1, and the internet protocol (IP) address are packaged as an Event 1 and provided to the brute force protection system. Event 1 is evaluated as described below in connection with FIG. 4, by determining whether a maximum number of events M(E) sharing the same request signature have been observed by the brute force protection system 102.
  • Event 1 is associated with the first request having a first signature (and less than the exemplary M(E) threshold of 4 in FIG. 2)
  • the system 102 returns Request 1 to the middleware with an action indicating that Event 1 is not associated with a brute force attack (e.g., the action may be to provide a response to the client or otherwise treat the associated request as a safe request).
  • the middleware provides Response 1 to the client device with the appropriate error code.
  • the middleware may provide a customized response in situations where the response is erroneous but not identified as a brute force attack.
  • the human user may then correct the erroneous iterable parameter value (e.g., by entering the passcode correctly at the client device), and submit the corrected value as part of Request 2. Because Request 2 does not generate an error code, the middleware provides the corresponding response (e.g., the requested resource) and is accordingly granted access.
  • the middleware provides the corresponding response (e.g., the requested resource) and is accordingly granted access.
  • a malicious bot 118 may provide a series of Requests 5 through 9 to the middleware as components of Events 5 through 9.
  • Malicious bot 118 is configured to guess values for each of one or more iterable parameters that are required for access to a requested resource at the middleware. Because the potential valid parameter space is so large, each of guesses five through nine presented via requests 5 through 9 are incorrect. (In practice, the probability that the parameter values in a brute force attack are wrong is very high because the space complexity of the parameters is large.) Metadata regarding each incorrect guess/request is provided by the middleware to the brute force protection system upon causing an erroneous response.
  • attempt threshold M(e) is 4, the first three Requests 5 through 7 are treated similarly to Request 1, even though each of Requests 5 through 7 are associated with the same request signature.
  • the system has reached the attempt threshold M(e) of 4, and the system 102 associates the request signature of Requests 5-9 with a likely brute force attack, and provides an appropriate Action to the middleware along with the corresponding Request, e.g. as described below in connection with process 300.
  • the Action for a Request that is associated with a brute force attack may be to delay providing the corresponding response to the client device/malicious bot.
  • the middleware may delay providing the response by an amount of time that is proportional to or based on the number of requests associated with the same request signature. Such a delay may slow down the malicious bot's ability to submit additional guesses/requests to the point where the attack becomes impractical, while still allowing a human user to continue trying to log in.
  • the malicious bot is associated with the same IP address ("IP5"), but in certain embodiments, multiple IP addresses could be associated with the same brute force attack.
  • FIG. 3 shows a flow chart for an exemplary process 300 concerning providing brute force protection.
  • a middleware device such as middleware server 108
  • a request for access to a resource is received (302).
  • the request is provided by a client device 114.
  • the middleware device either processes the request or provides the request to another device for processing, receiving its result.
  • the middleware determines whether the response resulting from processing the request includes a client error series code (e.g., 401 unauthorized, 403 forbidden, 404 not found, and the like) (304). If there is no error (e.g., the response status is not in the 400 series), the response is provided to the requesting client (314). If there is an error, the middleware creates an event object.
  • a client error series code e.g., 401 unauthorized, 403 forbidden, 404 not found, and the like
  • the event may include extracted information associated with the request and response—for example, a Request (e.g., information extracted from the request such as the request method (GET, POST, etc.), the requested resource or uniform resource identifier (URI or URL), the request header, and the request body), and may additionally include a Response (e.g., the response header and response status) and the client internet protocol (IP) address.
  • a Request e.g., information extracted from the request such as the request method (GET, POST, etc.
  • URI or URL uniform resource identifier
  • the event object is then provided to the brute force protection system 102 for processing as described below in process 400 (306).
  • the middleware next receives the result of the processing by the brute force protection system— for example, it may receive the Request and an associated Action (306).
  • the Action is used to indicate whether the Request is predicted as associated with a likely brute force attack or is safe, for example by providing an appropriate Action for the middleware to perform (310). Accordingly, in one example, the Action may indicate that the Request is safe or unlikely to be malicious, and that a response (e.g., including the error status) should be provided to the client device (314). If the Request was determined to be likely to be malicious, the Action may be to drop the Response (i.e., to not provide any response to the requesting client device) (312).
  • the Action may be to delay providing a response by a constant time (e.g., delay by 2 seconds), to use a linear delay in providing the response (e.g., delay by the number of failed attempts before now multiplied by a constant time, such as 2 seconds), to drop the response, to provide the response without delay, to block the requestor's access to the requested resource and provide a secondary access method (e.g., lock the user account and email the resource owner with a link providing access), to block the requestor for this and future requests (e.g., if the requestor can be uniquely identified, then block access from that source— for example, if an access token is mandatory for each request to the middleware, block requests using that access token); to provide a cipher challenge (i.e., provide a non-interactive challenge to the client that is not exposed to the human user and therefore not a Turing test— for example, the client CPU must take time to solve the challenge and respond with an answer, and set the complexity of the cipher challenge to be proportion
  • the Action may indicate that a particular iterable parameter is being targeted by a brute force attack, and instruct the middleware to respond appropriately—for example, for existing accounts or events, values for the targeted parameter may be reset or require resetting in accordance with more stringent security requirements, such as requiring a longer or more complex parameter value. In another example, for new accounts or events, more stringent requirements may be applied to new values for the targeted iterable parameter.
  • the Action may include notifying an administrator about the targeted parameter and/or brute force attack.
  • FIG. 4 shows a flow chart for an exemplary process 400 concerning providing brute force protection.
  • the process includes two options: first, a determination based on all iterable parameters, in which the brute force protection system 102 evaluates whether or not any of the iterable parameters in the request are being targeted by a brute force attack (i.e., the "collective parameter test," steps 404, 406, 408, 410, 412), and second, a determination whether one or more particular iterable parameters is being targeted by a brute force attack (i.e., the "individual parameter test," steps 424, 426, 428, 430, 432). Either option may be performed as an alternative, or both can be evaluated in parallel.
  • the targeted iterable parameter refers to the iterable parameter associated with varying values in requests involved in a brute force attack, as opposed to an iterable parameter associated with values that do not change across the series of requests involved in the attack.
  • a brute force protection system 102 receives an event object from a middleware device or service.
  • the event object includes a collection of event metadata— for example, information extracted from a request from a client device (a Request), a URL for the requested resource, information extracted from a response resulting from processing the request at the middleware (a Response) and the IP address associated with the client device.
  • an initial step is to determine a request signature associated with the event object (or a subset of its components) (404).
  • the request signature is created by replacing each of the iterable parameters in the event or a subset of the event, such as the Request, with a placeholder.
  • the request signature may be based on the Request. If there are n different iterable parameters in the Request, the resulting single signature may contain n placeholders.
  • a placeholder may be, for example, iterable parameter names (such as "passcode",
  • multiple request signatures may be determined for a single event, for example in order to base the request signature on different components of the event, such as including versus not including the IP address. Examples of an event and a corresponding request signature are provided below.
  • Example request signature based on the example event
  • the request signature may be based on one or more components of the event, for example, based on the Request, the Request.body and the URL, or the Request and the client device IP address, and the like.
  • malicious bot(s) 118 will vary the value for an iterable parameter across a series of requests (e.g., captured as a series of events), while ordinarily keeping the other features of the requests constant. Accordingly, after replacing the value of all iterable parameters with a placeholder to generate a request signature, each of the series of request signatures associated with the attack will be identical. In certain
  • an unmodified request signature is additionally created based on the original event information, without first replacing the values of iterable parameters with placeholders.
  • a single attack may be associated with requests originating from multiple IP addresses based on similar request characteristics.
  • the system 102 may track geo-colocation of requests, request fingerprints (based on all or parts of the header from each request), request sequence patterns (e.g., tracking the time differences between consecutive requests). New requests that match these request characteristics may be identified as associated with the same attack, despite being associated with different IP addresses.
  • the portion of the event used to determine the request signature (e.g., as determined in step 404) will not include the IP address.
  • the brute force protection system 102 is configured to store the event and the request signature associated with the event and/or the event's components in a database 104 (406). In certain
  • the unmodified request signature based on the original event information is also stored in the database.
  • the current event e and request signature E are stored in a hash table using the hash of a request signature E as a key.
  • the result of a hash function of event e is also used as a key for accessing event e in the table.
  • the database of prior events and signatures is used to evaluate a count of the number of times the system 102 has observed the current request signature E (408).
  • the system 102 additionally tests whether the current unmodified request signature is different across the different attempts— so long as the unmodified request signature changes while the request signature (i.e., containing placeholders) does not change, these circumstances indicate a brute force attack.
  • using a hash table allows the database to keep a running tally of the count for each request signature and access that count with efficient 0(1) performance, by incrementing a count value with each new event having signature E as a key.
  • events/signatures may be stored in a linked list retrieved by the key for the hash table, and counting certain of the identical request signatures may involve traversing that list.
  • the count of identical request signatures may be limited to events occurring during a certain time period t ending at the current time or the time event e was received, such as t ranging between one minute and one hour, such as 5 minutes, 7 minutes, 10 minutes, or 1 hour.
  • the time period for the count may depend on the category of event e. For example, a login event category may be associated with a longer time period, such as ten minutes, as login requests may occur with a relatively low frequency, and an event such as a request for access to a recording or a media item may be associated with a shorter time period, such as one minute or five minutes. For example, 20 failed login attempts in ten minutes is a potential brute force attack, but 20 failed media access attempts in five minutes is less likely to be a brute force attack.
  • Process 400 may be configured to use a threshold M(e), for assessing a maximum number of request attempts, above which a request signature will be treated as if it were associated with a malicious brute force attack request (410). Accordingly, if the count of identical request signatures for the current event (e.g., n(E)) is below the threshold, the request associated with the event will be treated as safe, or, for example, associated with an Action causing the middleware to treat the request in an ordinary manner, such as providing the default error response generated by the middleware. If the count is above the threshold, the request may be flagged as malicious, or associated with an Action instructing the middleware to treat the request as part of a brute force attack.
  • a threshold M(e) for assessing a maximum number of request attempts, above which a request signature will be treated as if it were associated with a malicious brute force attack request (410). Accordingly, if the count of identical request signatures for the current event (e.g., n(E)) is below the threshold,
  • the threshold may range between 25 and 50 attempts (e.g., observed during a one-minute time period t).
  • the time period t and attempt threshold M(e) (or the classification/determination of an attack more generally) may be set according to an event- type-dependent rate threshold, such as 2 failed attempts per minute for a login event type, and 4 failed attempts per minute for a media access request event type.
  • the threshold may be set based on the length or complexity of one or more of the iterable parameters associated with the event type, where the event type may be a category of client device request such as a request to join a videoconference, a request to login to a system, and the like.
  • an above-average human typing speed is 200 characters per minute.
  • a human could make a maximum of 25 attempts per minute, ignoring other factors such as network round-trip time.
  • a fast-typing human could make a smaller number of attempts per minute (e.g., 20 attempts per minute). Accordingly, a longer iterable parameter might be associated with a lower threshold such as a count of 20 attempts.
  • the threshold may be set to be lower than the threshold for a parameter value that is required to be comprised of numbers, symbols, and letters, because the former parameter value is likely to be guessed within a shorter number of attempts compared to the latter.
  • the resulting flag or Action, and Request or event may then be returned to the middleware (412).
  • an initial step is to determine a request signature associated with the event object (or a subset of its components), this time determining at least one request signature for each potential iterable parameter (424).
  • multiple request signatures may be determined for a single iterable parameter, for example in order to base the request signature on different components of the event, such as including or not including the IP address (i.e., with the IP address included, only brute force attacks from the same IP address would be detected).
  • the request signatures are created by, for each iterable parameter Ii, generating a request signature associated with replacing instances or values of Ii in event e with a placeholder. Stated another way, only one iterable parameter is replaced per request signature, as opposed to replacing all the iterable parameters in an event as with the collective parameter option. In certain embodiments, signatures may be generated only for a subset of iterable parameters present in the event, as well as an unmodified request signature.
  • Each request signature is stored in a database, for example in a hash table in which the hash of each request signature is a key for accessing the request signature and/or associated event in the table (426).
  • the database of prior signatures (e.g., hash table) is used to obtain a count for the number of times each request signature for each iterable parameter has been observed, resulting in a separate count corresponding to a signature for each iterable parameter (e.g., n(E(Ii))) (428).
  • the count is limited to a time period, for example, events associated with a date falling within the time period t.
  • Each count (associated with a parameter) is compared to a maximum attempt threshold (430).
  • request signatures for certain parameters are associated with a particular threshold, and in other embodiments, the same threshold is used for all parameters/request signatures.
  • the associated request is identified as likely part of a brute force attack targeting the certain parameter (432).
  • the brute force protection system 102 may then notify the middleware regarding the attack on the parameter.
  • the system may instruct the middleware with an Action for handling the event-associated request from the client device, where the Action is determined by whether or not any count exceeds a corresponding threshold.
  • FIG. 5 shows a block diagram showing an exemplary computing system 500 that is representative any of the computer systems or electronic devices discussed herein. Note that not all of the various computer systems have all of the features of system 500. For example, systems may not include a display inasmuch as the display function may be provided by a client computer communicatively coupled to the computer system or a display function may be unnecessary.
  • System 500 includes a bus 2506 or other communication mechanism for
  • Computer system 500 also includes a main memory 2502, such as a random access memory or other dynamic storage device, coupled to the bus 2506 for storing information and instructions to be executed by processor 2504.
  • Main memory 2502 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 2504.
  • System 500 includes a read only memory 2508 or other static storage device coupled to the bus 2506 for storing static information and instructions for the processor 2504.
  • a storage device 2510 which may be one or more of a hard disk, flash memory -based storage medium, magnetic tape or other magnetic storage medium, a compact disc (CD)-ROM, a digital versatile disk (DVD)-ROM, or other optical storage medium, or any other storage medium from which processor 2504 can read, is provided and coupled to the bus 2506 for storing information and instructions (e.g., operating systems, applications programs and the like).
  • Computer system 500 may be coupled via the bus 2506 to a display 2512 for displaying information to a computer user.
  • An input device such as keyboard 2514, mouse 2516, or other input devices 2518 may be coupled to the bus 2506 for communicating information and command selections to the processor 2504.
  • Communications/network components 2520 may include a network adapter (e.g., Ethernet card), cellular radio, Bluetooth radio, NFC radio, GPS receiver, and antennas used by each for communicating data over various networks, such as a telecommunications network or LAN.
  • processor 2504 may be implemented by processor 2504 executing appropriate sequences of computer-readable instructions contained in main memory 2502. Such instructions may be read into main memory 2502 from another computer-readable medium, such as storage device 2510, and execution of the sequences of instructions contained in the main memory 2502 causes the processor 2504 to perform the associated actions.
  • processor 2504 may be executing appropriate sequences of computer-readable instructions contained in main memory 2502. Such instructions may be read into main memory 2502 from another computer-readable medium, such as storage device 2510, and execution of the sequences of instructions contained in the main memory 2502 causes the processor 2504 to perform the associated actions.
  • hard-wired circuitry or firmware-controlled processing units e.g., field programmable gate arrays
  • the computer-readable instructions may be rendered in any computer language including, without limitation, Python, Objective C, C#, C/C++, Java, Javascript, assembly language, markup languages (e.g., HTML, XML), and the like.
  • Python Objective C
  • C# C/C++
  • Java Javascript
  • assembly language markup languages (e.g., HTML, XML), and the like.
  • all of the aforementioned terms are meant to encompass any series of logical steps performed in a sequence to accomplish a given purpose, which is the hallmark of any computer-executable application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

Des modes de réalisation de l'invention concernent la fourniture d'un service de protection contre les attaques par force brute à un service intergiciel, par exemple dans le contexte d'un système informatique distribué recevant des demandes de connexion en provenance de dispositifs clients distants. Le service de protection contre les attaques par force brute peut éviter de faire fond sur la présentation d'un défi de Turing au niveau de dispositifs clients pour identifier et gérer des demandes malveillantes d'accès ou de ressources au niveau du service intergiciel.
PCT/US2018/043834 2017-08-10 2018-07-26 Système et procédés de prévention active d'attaques par force brute WO2019032300A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
IN201731028514 2017-08-10
IN201731028514 2017-08-10
US15/788,635 2017-10-19
US15/788,635 US10362055B2 (en) 2017-08-10 2017-10-19 System and methods for active brute force attack protection

Publications (1)

Publication Number Publication Date
WO2019032300A1 true WO2019032300A1 (fr) 2019-02-14

Family

ID=63165526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/043834 WO2019032300A1 (fr) 2017-08-10 2018-07-26 Système et procédés de prévention active d'attaques par force brute

Country Status (1)

Country Link
WO (1) WO2019032300A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100192201A1 (en) * 2009-01-29 2010-07-29 Breach Security, Inc. Method and Apparatus for Excessive Access Rate Detection
US20140282866A1 (en) * 2013-03-13 2014-09-18 Ebay Inc. Systems and methods for determining an authentication attempt threshold
US20160057169A1 (en) * 2014-08-22 2016-02-25 Fujitsu Limited Apparatus and method
US20160197937A1 (en) * 2014-01-07 2016-07-07 Amazon Technologies, Inc. Hardware secret usage limits
CN106656640A (zh) * 2017-03-14 2017-05-10 北京深思数盾科技股份有限公司 网络攻击的预警方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100192201A1 (en) * 2009-01-29 2010-07-29 Breach Security, Inc. Method and Apparatus for Excessive Access Rate Detection
US20140282866A1 (en) * 2013-03-13 2014-09-18 Ebay Inc. Systems and methods for determining an authentication attempt threshold
US20160197937A1 (en) * 2014-01-07 2016-07-07 Amazon Technologies, Inc. Hardware secret usage limits
US20160057169A1 (en) * 2014-08-22 2016-02-25 Fujitsu Limited Apparatus and method
CN106656640A (zh) * 2017-03-14 2017-05-10 北京深思数盾科技股份有限公司 网络攻击的预警方法及装置

Similar Documents

Publication Publication Date Title
US10362055B2 (en) System and methods for active brute force attack protection
US9807092B1 (en) Systems and methods for classification of internet devices as hostile or benign
US9112828B2 (en) Method for defending against session hijacking attacks and firewall
US11122047B2 (en) Invitation links with enhanced protection
US8763078B1 (en) System and method for monitoring authentication attempts
US11330005B2 (en) Privileged account breach detections based on behavioral access patterns
US8869258B2 (en) Facilitating token request troubleshooting
US8856892B2 (en) Interactive authentication
US10320848B2 (en) Smart lockout
Preuveneers et al. SmartAuth: dynamic context fingerprinting for continuous user authentication
EP4022473A1 (fr) Authentification décentralisée de données
US9531749B2 (en) Prevention of query overloading in a server application
CN110690972B (zh) 令牌认证方法、装置、电子设备及存储介质
US9787696B2 (en) Brute force attack prevention system
US20200329025A1 (en) Preventing account lockout through request throttling
US11770385B2 (en) Systems and methods for malicious client detection through property analysis
US9092599B1 (en) Managing knowledge-based authentication systems
US11616774B2 (en) Methods and systems for detecting unauthorized access by sending a request to one or more peer contacts
CN113761498A (zh) 一种第三方登录信息托管方法、系统、设备及存储介质
US10284371B2 (en) Brute force attack prevention system
US12101315B2 (en) Systems and methods for rapid password compromise evaluation
US10255558B1 (en) Managing knowledge-based authentication systems
JP6842951B2 (ja) 不正アクセス検出装置、プログラム及び方法
WO2019032300A1 (fr) Système et procédés de prévention active d'attaques par force brute
CN111937361A (zh) 保护登录过程

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18752973

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18752973

Country of ref document: EP

Kind code of ref document: A1