Rate limit authentication attempts Apr 24, 2020 16:01:38 GMT
Post by josephreynolds1 on Apr 24, 2020 16:01:38 GMT
I would like to rate-limit excessive authentication failures. For example, a client contacting a Redfish server using Basic Auth or POSTing credentials to /redfish/v1/SessionService/Sessions/ would fail with HTTP status 429 "Too Many Requests" if there were too many recent authentication failures. This will go a long way to address CWE-307 (https://cwe.mitre.org/data/definitions/307.html) without suffering from account lockouts.
I want to be able to control rate limiting via new properties in the SessionService schema. The most obvious configuration parameters are:
- If rate-limiting is enabled.
- What number of attempts is considered excessive.
- The retry period (in seconds).
- The name of the rate-limiting algorithm (e.g., "sliding time window with 1 second granularity").
These are only the most obvious parameters. For example, the session service creates new sessions at full speed until it hits 2 authentication failures within 5 seconds. At that point, it gives HTTP status 429 for subsequent requests until it decides enough time has passed (related to the "retry period" above) and it is okay to continue processing auth attempts. The configuration parameters are 2 failures per 5 seconds.
One can easily imagine different rate-limiting algorithms that are sensitive to the account name or request origin, or treat the time-widows differently. I think the exact rate-limiting algorithm must be specified (see my example above). However, I am not currently interested in anything more complex than proposed here. EDIT Added: Some rate-limiting algorithms are described here: cloud.google.com/solutions/rate-limiting-strategies-techniques#techniques-enforcing-rate-limits
This is intended to work and play nicely with the existing AccountService schema lockout properties AccountLockoutThreshold, etc. For example, the BMC Administrator can choose to use account lockouts, authentication rate-limiting, both together, or neither. More specifically, rate-limiting can throttle attempt to guess usernames at the same time account lockouts protect admin accounts.