BMCWeb: rate-limit authentication failures

Joseph Reynolds jrey at
Wed Feb 5 09:41:12 AEDT 2020

I would like to enhance BMCWeb to rate-limit password-based 
authentication attempts (footnote1) to address [CWE-307][].  [Broken 
Authentication][] is an OWASP top 10 item.  The goal is to protect 
against CWE-307 without causing denial of service.  Specifically, when 
excessive authentication attempts are happening, legitimate users should 
be able to access the BMC (specifically an admin can login), and 
degraded BMC performance is acceptable.

The main idea for the design is to allow authentication at full speed, 
and rate-limit only when needed.   This is consistent with the approach 
OWASP outlines.

Perhaps the design can be as simple as recording the 10 most recent 
authentication failures (steady_clock time only, having them time out 
after a minute) to define "excessive", and using the timestamp of the 
most recent failure to determine when the next attempt will be allowed.  
When authentication is requested but not allowed, return HTTP status 
code 429 (Too Many Requests) with HTTP response header "Retry-After: 
3".  ==> This will slow down attackers (for example, to 30 tries per 
minute, even when multiple connections are used) and allow legitimate 
users to compete for authentication attempts.

However, I think even this apparently simple design might be tricky to 
get right.  Is there an open source solution we can use?  What do you 
think?  Let me know if this is important to you.  I would like to hear 
ideas how to proceed.

- Joseph

<snip/>TL;DR (too long; don't read):

A counterpart to this design is to delay any failed authentication 
attempt for a few seconds.  This is intended to slow down malfunctioning 
network agents that repeatedly fail to authenticate to the BMC.  This 
won't slow down attackers who can use multiple connections to the BMC.

I looked at using Linux-PAM.  For example, [OpenBMC uses pam_tally2][] 
but does not configure account lockouts.  I don't want to pursue using 
the pam_tally2 lockout mechanism because that can lead to denial of 
service.  I believe rate-limiting is a better approach.

I only want to protect access via BMCWeb.  The protection techniques may 
also apply to network IPMI and SSH, but the direction is to disable 
these accesses, so I am less interested.  Access via the BMC's serial 
console would not be protected.  Access via the BMC's host should have 
similar protections, but I am not investigating that now.

CWE-307 is a problem only because OpenBMC offers password-based 
authentication without requiring multi-factor authentication (MFA). 
Disabling password-based auth remains a popular use case, and OpenBMC 
has no MFA capabilities.  So I need CWE-307 protection as a stop-gap 

References and footnotes:
[OpenBMC uses pam_tally2]:
(footnote1): BMCWeb's password-based authentication includes Basic Auth, 
login via /login, and creating a Redfish session.  It does not include 
authentication via mTLS or using an X-Auth-Token or a cookie from an 
established session.
[Broken Authentication]:

More information about the openbmc mailing list