Thanks for bringing this up. In general, if you believe there is a security-related issue in ODK tools, please do use the vulnerability disclosure process.
While we can provide some ideas and advice on how to run a secure Central deployment, please note that it is the service provider's ultimate responsibility to harden their installation according to their needs. Security is all about tradeoffs and what makes sense in one context on one type of infrastructure may not make sense in another.
There is no HTTP rate limiting, that's correct. However, Central uses bcrypt for password storage which provides its own form of rate limiting. Password validation is limited by the server's CPU. For example, a server with 2 CPUs at about 3GHz can only process about 20 password validation requests per second.
The appeal of bcrypt is that passwords take time to brute force even if hashed passwords are leaked and an attacker has direct access to them. Central requires at least 10 characters in a password.
If you believe you are at particular risk for brute force and denial of service attacks, consider using a service like Cloudflare. They have options for features like managed challenges, an improvement over always showing a CAPTCHA.
The strategy @yanokwa described above can also be a really good one if you know where your traffic is supposed to come from.
If they do believe they can reproduce a brute force attack, please ask them to share with us using the vulnerability disclosure process.
@alxndrsn has been thinking through this with us -- please add anything you think would be valuable to this conversation!