Attack vectors for brute-forcing website passwords

Question

When talking about password security, a lot of discussion centers on the risk of a password being guessed in a brute-force attack. For websites where a user has registered an account, what are the possible vectors for a brute-force attack?

Entering username/password pairs into the website authentication fields directly is one, but is often mitigated by a timeout or lockout after failed attempts. Carrying out an attack on a stolen database of hashed passwords is another, but assumes the database has been compromised. How else could a brute-force password attack be carried out (assuming we're talking about website accounts, not Unix accounts, services, etc.)?

Answer 1

How else could a brute-force password attack be carried out?

You've covered both bases, and that's really about it. Either repeatedly submit to whatever web frontend is available, or manage to get a copy of the hashes by cracking the database server, abusing the web software, what have you.

Web frontend cracking is usually more an issue of smart force than brute force, and as a result, it works better than you would assume. For example, given a web site which had a company directory - first, last, and extension - for about 100 people, I was able to "brute force" 30% of the accounts simply by throwing together some algorithmic guesses with that data. And the authentication site was Microsoft Exchange, so I stayed below the threshold of NSA recommended lockouts and was fine. (In fact, this was a pen test and I verified before testing to ensure I wouldn't lock out users, but it was an easy guess to make correctly). Even with the slow rate of guessing, I was done in under a day.

Answer 2

I have seen a fair share of sites that change behavior based on the supplied credentials; submit a username that does not exist and you may possibly get a unique error message or a quicker HTTP response versus submitting a legitimate username/password pair.

One idea - let’s say you successfully steal a valid session of a logged in user and the password change functionality requires you enter in the user’s existing password – you may be able to successfully brute force the password change form without triggering lockouts or captchas to discover the original password.

Answer 3

Gowenfawr already covered user-enumeration (if I understood it correctly).

Most systems (if not all), the lockout policies are for each account. So it should be possible to iterate over all the users you know, trying an amount of passwords that would keep you below the lock-out threshold for each account. And once the grace time for invalid logins have been reached, you try again.

Wouldn't this also be very close to a birthday attack on users password?!

I read an article about a student who did something similar to an online bank. The username was the social security number, and the average bank customer was a male between 30-40 year old. He generated random social security numbers for this age group, and tried different pins (the login was only 4 digit pin code!). I believe he was able to get access to an online bank account for every ~20k attempt.

Answer 4

The reason brute-forcing is a popular discussion topic is largely pop culture: it is relatively easy to understand by people who don't understand how computers work, so there are many tropes and common depictions of this class of attacks. Their practical feasibility is more limited.

That having been said, homebrew software systems are often vulnerable in ways that thoroughly analysed systems tend to protect against. For example, adequate implementation of lock-out requires collection and storage of certain data on a per-user and per-client basis. It is not uncommon for inexperienced programmers to be unwilling or politically unable to, say, define the extra SQL fields or tables, and thus neglect to implement a lock-out policy. It is a general rule of thumb that systems designed without proper security analysis tend to overemphasise the accessibility aspect of data security, and underemphasise the confidentiality aspect, and since lock-out has immediate implications for accessibility, it may even be disfavoured by some organisations with websites.

Answer 5

In theory, brute-force attacks should be limited to a very small set of possible scenarious, for the simple reason that if your authentication system does not protect against brute-force attacks it is broken, period.

In reality, a lot of authentication systems are broken and do, in fact, allow brute-force attacks. Their protections are either nonexistent or not effective.

Additionally, as you correctly guessed, you can do a brute-force attack if you control the execution, i.e. if you have the password database, or the ciphertext or whatever else data you want to attack.

There is also one specific sub-set of brute-force attacks where the protection against brute force is bypassed. In hardware, you can sometimes disable the brute force protection, or return the device to a previous state (e.g. recover from backup) and try again. This is a very specific scenario with very narrow conditions to make it work, but there was an iPhone case a few years ago where the FBI tried this approach, apparently successfully.