Could a security professional explain in non-domain-expert terms why this practice isn't simply adopted everywhere?
Could a security professional explain in non-domain-expert terms why this practice isn't simply adopted everywhere?
1. User support. How willing are you to deal with increased need for customer support when they start locking themselves out of their accounts after a dozen failed attempts?
2. How do you keep track of the number of failed attempts? Another column in your database? I don't run any big websites, but it seems to me that if an attacker can cause a write to your DB for every POST he can throw at you, your website performance will suffer.
3. If it takes a dozen (or a hundred (or a thousand)) failed logins to lock an account, it would be trivial for an attacker to lock users out of their accounts, DOSing your site in a different way.
4. Ok, so we block IP addresses instead of accounts? Now we have to deal with issues of shared or easily changed IP addresses (or botnets that can afford to have hundreds of thousands of IPs blacklisted from a site and still keep brute forcing).
A lot of these issues are surmountable, but not until you do some basic threat modeling to decide what you want to protect against.Maybe you decide to focus on preventing from attackers coming from one IP from slamming your site, so you keep an in-memory table of number of recent failed logins and perform temporary bans. It wont protect against botnets, but hopefully you are paying attention to what is happening on your site, and can make changes if that becomes an issue.
> yet most password security guidelines still warn against what they consider brute-forceable passwords.
Your password should be hard to brute force, regardless of whether or not the site protects itself from brute forced logins. The other big danger is that someone hacks the site and gets a dump of password hashes. Then, it doesn't matter what anti-brute force techniques the website is using if the attacker can perform an offline brute force attack against your hashes.
Not too inconvenient for legitimate users trying to remember their passwords, but it surely makes bruteforcing impossible (if by the 1,000th attempt they're having to wait an hour between attempts).
* Phone/number that is redirecting a call pays for the redirected leg of the call
This leads to a lot of creative hacking on trying to program a phone to redirect calls to expensive service numbers or foreign numbers. And many operators lets you administer call redirection on their website
It's no less secure than a password reset and would mean that legitimate account owners can't be locked out of their accounts by attackers.
There's not anything wrong with that either. As humans, we have limited available attention. You and I might argue that security is critical, but even thinking about everything that is reasonably deemed critical is paralyzing. Statistically organizations are just not going to take security seriously on the whole until they get pwned to the tune of billions.
Oh, and DDOS has nothing to do with rate limiting. If you fill up a pipe with incoming packets it's going to become unresponsive. There's no real way to stop it, but multi-homing, global distribution and some tricks administered by DDOS mitigation companies can help.
The greater the restrictions on the account lockout policy, the more personnel you need to hire (salary, health benefits, pension, 401k) to deal with people who manage to lock their accounts out.