Ethical brute force demo on a web login when knowing the password complexity requirements

Question

We are currently having accounts compromised at a substantially high rate. Some in the organization believe that our password complexity requirements is enough to thwart brute force attacks.

I wanted to test and demonstrate how certain password complexity requirements can actually reduce the password search space.

Has anyone done this before? What tools should I look into? I specifically would prefer to test it on our Exchange 2010 OWA web page since that is publicly accessible and not rate limited at the moment.

Answer 1

It depends on the complexity requirements you're implementing and the baseline you're coming from. If your existing passwords are baseball and passw0rd and 123456, then anything is an improvement.

But the easy way to test complexity is to check to see how many characters are used from each of a given class (e.g. uppercase, lowercase, numbers, symbols). It's easy to program but it's also a very poor estimation of password quality.

The javascript library zxcvbn was designed by Dropbox to give a more realistic estimation of password quality based on factors that actually matter when cracking passwords. Have a look at their writeup here on their blog for the how and the way.

The basic gist is this:

• Common passwords are really bad, and fail regardless of composition
• Long passwords are better than short passwords
• A wider character set increases the incremental advantage of each additional character in length
• Known dictionary words are scored as components of a dictionary, not as the sum of their characters

Answer 2

While it is true that password complexity requirements do reduce the possible search space I'm not sure this is exactly what you're looking for.

Maybe you are referring to the habits of some people to go with more predictable choices (like "Password1") when required to have a mix of lowercase, uppercase, numbers, or symbols. While it is true that implementing password complexity does not prevent use of some weak passwords, it does eliminate the worst of the worst (like "password" and "123456"). But you are right that turning on complexity is not a solution to poor passwords by itself.

If you have evidence that someone is brute forcing passwords over OWA then the logs of the attempts and successes should be enough to show that password complexity is not effective enough. I'm not sure your demonstration of this attack in action would do much more to sway their opinion. And if you are unsuccessful it may actually strengthen their belief that nothing is wrong.

If your goal is to highlight general weaknesses in your fellow employees' password choices then I would suggest password cracking/analysis rather than online brute forcing. It should yield many more weaker passwords in a shorter timeframe which should help highlight any widespread password problems.

Answer 3

You can use Burpsuite or OWASP ZAP to do this testing, but you shouldn't even have this issue.

Consider limiting the number of password guesses that can be made for a given username/IP/etc. before a lockout occurs.

This, in addition to a good password policy, will drastically limit the ability of attackers to harvest accounts.

Answer 4

To deal with bruteforce you can use an old trick. Use threads and put them on sleep (thread.sleep) if there is fail login and extend the sleep time or double it on every fail login after. Basically the more the attacker tries to more waiting time he gets.