: how can brute forcing password still exist if sites lock the account after several failed attempts?
In: 536
Locking out an account is a great way to stop brute force attacks. Not every site will do this though.
The majority of attacks will come from people getting hold of a database leaked from a website with your password in it, and then trying your username and password on that website but also many other popular websites.
The good news is that a good website will hash your password, so you can’t just read it from the database. However if the attacker has the database they can use a brute force attack to decode those hashes.
Always use a secure password (20 random characters, or 3 words).
Never reuse passwords between websites.
Because you don’t brute force the live system directly. Attackers will have obtained a copy of the password database, and can attack it locally on their own system, where lockouts or other controls aren’t a factor.
There is more than one way to brute force a password. The purpose of a lockout is to prevent this exact type of attack, but if the attacker can get more information they can get around this lockout. Servers *usually* store password using something called a hash which is a “number” that is calculated using an algorithm that cannot be done in reverse, a password can be put through a hash algorithm and the returned hash can be stored. When someone tries to log in the server generates the hash of the password you just typed in and if its the same as the one it has stored you are logged in.
If an attacker gets the password hash database and knows which algorithm they use, they can try to brute force the password without trying to log in to the site. Once they have a password that matches the original hash they can enter that into the site and thee will be able to log in.
Usually the concern is that a data leak could result in someone getting hold of the hashed password (the scrambled version the service keeps in their database to check you entered the right password).
If someone has the hashed password they can try to guess it and check if they were right as many times as they want on their own computer.
If they find a password that works they can then use it on the real service, or other services you might use the same password for, and get it right on the first try.
We can copy the system we’re trying to crack so that we can make as many attempts as we want regardless of lockout. For example, if I have your iPhone, with about an hour of “surgery” I can read the memory and onboard storage directly, and then it becomes trivial to clone your phone into a computer system that can create 10000 copies and brute force while reloading each phone that gets locked out.
Rule 0 is physical security. If I have physical access to your raw data, be it a copy of your hard drives, or your phone in my hand, you’re already screwed. No amount of security can stop me if I have the full data and system.
People like the FBI and CIA who have the budget to clone a criminal’s devices to 100k+ instances in a data center can just let it run for a week and decrypt. And yes, we can also spoof authentication servers and other checks your device might make to see if it’s “legit”. We can brain-in-a-jar your devices and they have no way of knowing.
1. Few sites lock accounts after failed attempts. Otherwise, an attacker could still try, until the account is locked, and then the real user would be unable to get in.
2. Classic “aaaaaaaa, aaaaaaab” style brute force doesn’t happen online (by trying against a site live). Dictionary attacks may sometimes happen, but usually site A gets hacked, leaking hashed forms of passwords. You can’t read the password, but you can test whether a password matches the hash.
Bruteforcing the hashes, i.e. trying passwords until one fits the hash, is being done – but since the attacker has the entire database, they can do it “at home” without talking to the site, so no limit applies (except the time/computing capacity needed to calculate the hashes for testing).
Once the attacker has bruteforced a password, they may then possibly use it to log in to the site, but most importantly they will try the same username-password combo everywhere else. They only need one attempt per account! (They may try variants like adding different numbers, but it’s generally a small number of attempts.)
That’s why it’s so important to have completely different passwords for every site.
In addition to what has already been answered here regarding brute force attacks directly on the database, for example, it should be noted that the solution itself is a problem.
Enabling brute force protection is great for stopping a hacker who is attempting multiple passwords on a given account, but the downside is that the legitimate account owner will also end up being blocked.
If generic scripts regularly bombard your sites to detect accounts with weak passwords, resulting in frequent blocking of your users, you cannot keep this protection in place.
A security expert explained to me the basic math. 1 million accounts, 3 passwords, and presto.
You want to know someone’s password. They have it written down in a book in their house, but that book is encoded in some format that only the person knows. Trying to brute force the password online would be like going up to the person’s house and knocking on the door and asking them if their password is A. They say no and close the door, so you knock again and ask if it’s B. They say no again, and when you knock this time they just lock the door and don’t answer it anymore. So instead when it gets dark you break into their house and steal the password book. It’s still encoded, but it’s a lot easier for you to try and work on the scrambling this way.
[removed]
Latest Answers