Edit: Thank you everyone who’s taken out time to explain it to me. I’ve learnt so much. Appreciate it.
Yes, I do use ‘thrice’ in my conversation whenever required. I’m glad it amused so many of you.
In: Technology
The answers given so far all seem to be correct, but appear to answer a different question than the one asked.
You are 100% correct that if attackers use the same website/system to attempt a login, then they will also get locked out too.
Consider this flowchart/steps needed to login
1. Type details into your web browser and click submit
2. The web server computer receives this data and decides whether to continue or not (e.g. auto reject if you’ve tried too many times)
3. The web server computer then communicates with the database server computer to see if the data you submitted matches the data they have stored (I.e. username/password/email address/whatever)
4. The database replies with the relevant information/data for the web server to use
5. The web server computer then responds to the user with the relevant response (e.g. “no” if it doesn’t match up)
What if you could trick step #2 into always allowing you through, or what if you could skip around steps 1+2+5 and have the database respond directly to you?
The first way around this is to figure out how they determine “repeated attempts to login” (i.e. step 2) – e.g. they might be counting the number of attempts coming from a specific computer/IP address etc, in which case they will just use lots of different computer to get more attempts (e.g. a network of remotely/robotically controlled computers – a botnet). This doesn’t work if they’re counting the number of attempts to login to a specific account though as it won’t matter WHERE the attempt came from, just that an attempt was made.
Another way around it is to bypass the checks/counting. Wherever the counting is taking place, if you can avoid that then you no longer have a limit on the number of attempts you’re making. One option might be to find some way to reset the counter, but in practice this typically means getting direct access to the database and running your attacks against that. When you have direct access to the database (either the live one with protections bypassed, or a local copy of it that you downloaded) then you have as many attempts as you want/need.
Other answers go into substantial detail about what is normally stored within the database and how that is attacked, but that is mostly irrelevant when considering the number of attempts made.
Latest Answers