How do you manage password brute force and credential stuffing attacks in your application?

If you're asking about user/client-facing passwords and not like API keys: I think offering a two-factor auth (2fa) option is always a good first step. "have i been pwned?" seems to offer an API: https://haveibeenpwned.com/API/v2 AFAIK, Chrome, Firefox, and Safari have features that can warn users when their credentials are leaked/compromised. Services like Auth0 seem to handle breach detection as well: https://auth0.com/docs/attack-pr... Captchas, password attempt limits, and password strength evaluators are good measures against brute force attacks as well AFAIK. I've never implemented these features in my projects from scratch, and typically rely on services like Auth0.

This is really a problem that I've always felt belongs more to the realm of economics more than anything truly technical. Credential stuffing attacks are by their nature extractive and so you can either design your system in a way where such an attack would yield little end product worth the attack's time, and then use some basic mitigation like a reCaptcha-like service to stop the proverbial doorknob jiggling. Alternatively, since not everyone has the luxury of having that much control over essentially how a business presents itself online in whole, there are ways to up to cost of the attacks for the attacker so that it becomes economically no longer worthwhile to at least use this form of attack. When considering this broad approach, you'd definitely need to go check out what these attacks are actually creating in value for the attackers in the marketplace instead of making assumptions because these are low margin high volume types of work where a little creativity can make a lot of difference to their bottom line and blindside you entirely. I think it's extremely unlikely to, via some sort of code-based measure alone, stop all attacks. If there's enough value to extract, someone will go through the trouble to reverse engineer a solution or team up with people with different expertises or think way outside of the box to make it work. But you can certainly make it not worth their time and effort and ultimately disincentivization is key. The more complex your technical mitigation efforts run the less responsive you will be without additional expenditures, and also what makes the attacks frustrating will inevitably affect the experience of your actual customers. People reuse passwords because it's the natural thing to do - to assume that your personal secret is personal and secret. People don't like 2FA because it's annoying (and sometimes poorly implemented as to be counterproductive). Password managers either cost money or require a level of technical expertise that may not seem like much to us but appear insurmountable even to my parents. I think keeping the actual login aspect as unobtrusive as possible is very important and all the fancy password rules and QR code scanning will inevitably affect your actual customers. Instead, if your local laws allow for it, think about creating a system where even an ostensibly successful attack may yield little actual financial value. Don't collect customer PII that you aren't really going to need, for example. Find a way to separate out the elements needed to financially exploit a breached account, like instituting a cool-down period between a password change and a giftcard pin recovery, or something in that general sense. It should be noted that if you go on Github and do a search and don't see some sort of brute force program or exploit or tool for a certain commercial solution it's just as likely that the solution is simply being actively monetized or the vendor's DMCA team is more on the ball than anyone else in the company. All that is more or less out of your control after you integrate it into your stack - visual captchas that were perfectly workable solutions 5 years ago can now be trivially bypassed with machine learning or the very affordable services of some Russians, after all - but a system designed to minimize financial incentives to be had can last a lot longer, and is something you can at least control. I realize that offering some security vendor out as the go-to and one-stop-shop is an easy way to both diffuse personal responsibility and reduce your workload. But without planning around the concept of disincentivizing such attacks, it's like the TSA doing security theater at the airport - cosplaying security instead of a serious attempt at mitigation ahead of time.

I use Auth0 for my SaaS services and password services for my own passwords and always 2FA.

Interesting choice of tool But I am more curious on whether such services prevent brute forcing and credential stuffing attacks to safeguard your application? What is your experience on those elements, if you may care to answer please?