edtanous
commented
3 years ago This is to track BMCWeb defenses against password guessing attacks. Specifically, when authentication fails the response should take a few seconds before replying.
This is not specific to bmcweb. bmcweb calls into pam (similar to SSH and IPMI) which is where this fix needs to go.
- Do we need to limit the maximum number of unauthenticated connections so we don't give attackers another way to cause DoS?
Yes, but we should limit by IP address. Putting an arbitrary limit on number of connections just means an attacker can open that many connections, and DOS other people from connecting.
- What is the right way to do this so we don't leak information about what accounts exist via how long BMCWeb takes the process each request? [edit:] Can we leverage the existing BMCWeb per-connection timer to ensure we get a consistent delay no matter if the account exists or not?
No. pam should return a consistent timing regardless of whether or not an account exists or not.
Background: Excerpts from email archive: https://lists.ozlabs.org/pipermail/openbmc/2020-September/023043.html The problem we wish to solve is to stop or make brute force password attacks logistically impossible/useless, but still allow credentialed individuals in. ... I still think a simple 2-4 second delay (without the 30 second delay) is more than sufficient.
This is to track BMCWeb defenses against password guessing attacks. Specifically, when authentication fails the response should take a few seconds before replying.
Background: Excerpts from email archive: https://lists.ozlabs.org/pipermail/openbmc/2020-September/023043.html The problem we wish to solve is to stop or make brute force password attacks logistically impossible/useless, but still allow credentialed individuals in. ... I still think a simple 2-4 second delay (without the 30 second delay) is more than sufficient.