Method and apparatus for trust-based, fine-grained rate limiting of network requests

• US 10,021,081 B2
• Filed: 02/12/2010
• Issued: 07/10/2018
• Est. Priority Date: 11/18/2003
• Status: Active Grant

• Current Assignee: Meta Platforms, Inc. (f/k/a Facebook, Inc.)
• Original Assignee: Meta Platforms, Inc. (f/k/a Facebook, Inc.)
• Inventors: Toomey, Christopher Newell
• Primary Examiner(s): Khoshnoodi, Nadia
• Application Number:
  US12/705,365
• Publication Number:
  US 20100146612A1
• Time in Patent Office: 3,070 Days
• Field of Search: None
• CPC Class Codes: G06F 21/31 User authentication
• CPC Class Codes: G06F 21/33 using certificates
• CPC Class Codes: H04L 2209/42 Anonymization, e.g. involving pseudonyms
• CPC Class Codes: H04L 2209/76 Proxy, i.e. using intermediary entity to perform cryptographic operations
• CPC Class Codes: H04L 2209/80 Wireless
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/123 received data contents, e.g. message integrity
• CPC Class Codes: H04L 63/126 the source of the received data
• CPC Class Codes: H04L 63/1458 Denial of Service
• CPC Class Codes: H04L 9/002 Countermeasures against attacks on cryptographic mechanisms network architectures or network communication protocols for protection against malicious traffic H04L63/1441
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853
• CPC Class Codes: H04L 9/3297 involving time stamps, e.g. generation of time stamps

Abstract

A method and apparatus for fine-grained, trust-based rate limiting of network requests distinguishes trusted network traffic from untrusted network traffic at the granularity of an individual user/machine combination, so that network traffic policing measures are readily implemented against untrusted and potentially hostile traffic without compromising service to trusted users. A server establishes a user/client pair as trusted by issuing a trust token to the client when successfully authenticating to the server for the first time. Subsequently, the client provides the trust token at login. At the server, rate policies apportion bandwidth according to type of traffic: network requests that include a valid trust token are granted highest priority. Rate policies further specify bandwidth restrictions imposed for untrusted network traffic. This scheme enables the server to throttle untrusted password-guessing requests from crackers without penalizing most friendly logins and only slightly penalizing the relatively few untrusted friendly logins.

Claims

1. A method comprising:

for each successful authentication, adding or updating a database record in a database containing at least a user identifier, an IP address agnostic client device identifier, an originating network address, and a date/timestamp of a first or previously successful authentication;

determining whether a user identifier of a subsequent request matches the user identifier of a database record associated with a previously successful authentication;

determining whether a client device identifier of the subsequent request matches the IP address agnostic client device identifier of the database record associated with the previously successful authentication;

processing, using at least one processor, the subsequent request according to a first policy if both of the user identifier and the client device identifier of the subsequent request match the user identifier and the IP address agnostic client device identifier of the database record associated with the previously successful authentication; and

processing, using the at least one processor, the subsequent request according to a second policy by adding a configurable amount of response latency if the client device identifier of the subsequent request does not match the IP address agnostic client device identifier of the database record associated with the previously successful authentication.

2. The method of claim 1, further comprising determining a trusted address range from stored authentication database records matching the user identifier of the subsequent request.

3. The method of claim 1, wherein the configuring the added amount of response latency comprises adding a delay period before processing the subsequent request.

4. The method of claim 1, wherein the configurable amount of response latency increases incrementally with each subsequent request from the client device where one or more of the user identifier and the client device identifier of the subsequent request does not match the user identifier and the client device identifier of the database record associated with the previously successful authentication.

5. The method of claim 4, further comprising resetting the configurable amount of response latency when a second subsequent request from the client device matches the user identifier and the client device identifier of the database record associated with the previously successful authentication.

6. A method comprising:

for each successful authentication to a network service, creating a database record in a database for an entity if the entity has not previously authenticated to the network service, the database record containing at least a user identifier, an IP address agnostic client device identifier, an originating network address, and a date/timestamp of a first or previously successful authentication;

determining whether a user identifier of a subsequent request matches the user identifier of a database record associated with a previously successful authentication;

determining whether a client device identifier of the subsequent request matches the IP address agnostic client device identifier of the database record associated with the previously successful authentication;

processing, using at least one processor, the subsequent request according to a first policy if both of the user identifier and the client device identifier of the subsequent request match the user identifier and the IP address agnostic client device identifier of the database record associated with the previously successful authentication; and

processing, using the at least one processor, the subsequent request according to a second policy by adding a configurable amount of response latency if the client device identifier of the subsequent request does not match the IP address agnostic client device identifier of the database record associated with the previously successful authentication.

7. The method of claim 6, further comprising determining a trusted address range from stored authentication records matching the user identifier of the subsequent request.

8. The method of claim 7, wherein an address of a client device requesting the subsequent request comprises an IP address, and the trusted address range comprises a trusted range of IP addresses.

9. The method of claim 7, wherein the trusted address range comprises a set of multiple trusted address ranges.

10. The method of claim 6, wherein the configuring the added amount of response latency comprises adding a delay period before processing the subsequent request.

11. The method of claim 6, wherein the configurable amount of response latency increases incrementally with each subsequent request from the client device where one or more of the user identifier and the client device identifier of the subsequent request does not match the user identifier and the client device identifier of the database record associated with the previously successful authentication.

12. A system comprising:

at least one server; and

at least one non-transitory computer readable storage medium storing instructions that, when executed by the at least one server, cause the system to;

for each successful authentication, update a previously created record in a database for subsequent authentication requests from an entity, the record containing at least a user identifier, a client device identifier, an originating network address, and a date/timestamp of a first or previously successful authentication;

detect a subsequent request from an anonymous client device;

determine a trusted address range for a user identifier of the subsequent request from stored authentication records;

determine whether a client device identifier of the subsequent request matches the client device identifier of the record associated with a previously successful authentication;

determine whether the subsequent request from the anonymous client device has an address within the determined trusted address range;

process the subsequent request according to a first policy if the subsequent request from the anonymous client device has an address within the determined trusted address range and if the client device identifier of the subsequent request matches the client device identifier of the record associated with the previously successful authentication;

process the subsequent request according to a second policy by adding a configurable amount of server to client device response latency if the subsequent request from the anonymous client device has an address outside of the determined trusted address range or if the client device identifier of the subsequent request does not match the client device identifier of the record associated with the previously successful authentication; and

extend trust if the user identifier and the client device identifier of the subsequent request match the user identifier and the client device identifier of the record associated with a previously successful authentication.

13. The system of claim 12, wherein the address of the client device requesting the subsequent request comprises an IP address, and the trusted address range comprises a trusted range of IP addresses.

14. The system of claim 12, wherein the trusted address range comprises a set of multiple trusted address ranges.

15. The system of claim 12, wherein the anonymous client device is not capable of storing and replaying a server-generated trust token.

16. A system comprising:

at least one server; and

at least one non-transitory computer readable storage medium storing instructions that, when executed by the at least one server, cause the system to;

for each successful authentication to a network service, create a record in a database if an entity has not previously authenticated to the network service, the record containing at least a user identifier, an IP address agnostic client device identifier, an originating network address, and a date/timestamp of a first or previously successful authentication;

determine whether a user identifier of a subsequent request is associated with a client device that includes a trust token;

determine whether a client device identifier of a subsequent request matches the IP address agnostic client device identifier of the record associated with the previously successful authentication;

process the subsequent request according to a first policy if the client device contains the trust token and the client device identifier of the subsequent request matches the IP address agnostic client device identifier of the record associated with the previously successful authentication;

process the request according to a second policy by adding a configurable amount of response latency if the client device contains the trust token and the client device identifier of the subsequent request does not match the IP address agnostic client device identifier of the record associated with the previously successful authentication; and

extend trust if both of the user identifier and the client device identifier of the subsequent request matches the user identifier and the IP address agnostic client device identifier of the record associated with a previously successful authentication.

17. The system of claim 16, wherein the instructions, when executed by the at least one server, cause the system to extend trust further by extending trust if a timestamp associated with the subsequent request passes a configurable bounds check.

18. The system of claim 16, wherein the network service comprises a server.

19. The system of claim 18, wherein the client device and the server are in communication via a secured network channel.

20. The system of claim 19, wherein the secure channel comprising a network connection secured via a secure sockets layer protocol.

21. The system of claim 16, wherein the configurable amount of response latency incrementally increases with each subsequent unsuccessful authentication attempt from the client device.

22. The system of claim 21, further comprises instructions that, when executed by the at least one server, cause the system to reset the configurable amount of response latency when a second subsequent request from the client device matches the user identifier of the database record associated with the previously successful authentication.

23. The system of claim 16, wherein the instructions, when executed by the at least one server, cause the system to process the subsequent request according to the second policy further comprises requiring an untrusted entity to complete a turing test.

24. The system of claim 16, wherein the first and second policies are applied by a server.

25. The system of claim 16, further comprising instructions that, when executed by the at least one server, cause the system to determine that an address of the client device is within a trusted address range based on stored authentication records matching the user identifier of the subsequent request.