My client has a server that is being subjected to brute-force login attempts from a botnet. Due to the vagaries of the server and the client's client, we can't easily block the attempts through a firewall, port change, or login account name change.

The decision has been made to leave it open to attack, but find a method of keeping the password secure. Management and some of the other consultants have determined that the best thing to do is to install password rotation software to rotate the password every ten minutes and provide the new password to users that need to log in.

The brute force attempts are occurring twice every second.

I need to demonstrate that implementing a strong password with 12-15 characters is an easier and free solution. I know how to prove this with math, but I'd just be writing something like "there are x many possible permutations of our password, and the attacker can only try n attempts per day, thus we'd expect them to go x/2n days on average before they guess our password." Is there a more standard "proof" of this?

11 Answers
11

Mixed upper and lower case alphabet and common symbols, 8 characters long, gives you 2.9 quadrillion conbinations and with 10,000 attempts a second will take 9,488 years. Thats the maximum of course - expect your password to be cracked in 4000 years. 1000 years if you're not feeling lucky.

As you can see you shouldn't have any issues if you do a 15 character password like:

the only issue you'll have is that nobody can remember their passwords..
–
Jeff Atwood♦Jul 21 '09 at 8:53

That is a really interesting link, but I have noticed (at the bottom of the page) that their attack times are based around Pentium 100s! Perhaps a little out of date now, but still a good read.
–
CoopsJul 21 '09 at 11:44

If you're running any modern UNIX, you can generally change the bad password entry sleep time to up to 5 seconds, slowing the attack speed by 2000%. [Solaris 10 has it in /etc/default/login, search for SLEEPTIME] Which using the same tolerances would mean you could rotate the password every 3hrs 20 minutes.

Also, password tries before lockout would be a viable option, but I suspect it is not for you because you have multiple users sharing one account and do not want it locked out all the time.

Requiring a 12-15 character password helps, but if you are continually being attacked another solution is probably better. I don't know what your company's budget tolerance on this is, but RSA key cards for everyone who needs to log into that account would solve it as well. Two factor authentication pushes the probability out into quantum computing time.

The brute force approach going on long enough for you to post on this board is pretty surprising. Generally speaking it's pretty lowbrow and at best is a log filler while a real attack is going on.

How about an appeal to authority? You could reference the DoD Security Technical Implementation Guidelines (iase.disa.mil/stigs/stig) and say "If it's good enough for the Defense Department, it's good enough for us"

Something to consider: if you have a password that doesn't change, and the brute force attacks are testing a universe of passwords that includes yours, the brute force attack is guaranteed to hit eventually and you will remain vulnerable after that.

The "chance" that a random pick will hit your password can be calculated, as you've suggested, but that may not tell the whole story.

If you look at the brute force attempts, for example, and see that the longest password they try is 10 characters, picking anything at 12 will ensure you will never get hit.

Be very careful when trying to apply statistics to a particular case; they only predict the overall behavior with a large number of samples.

That aside, if the mathematics don't (or can't) convince someone, try to find something that has about the same chance of occurring but is familiar, like perhaps lotteries or car accidents or struck by lightning. If you can say "the chance of someone hitting this password is about the same as winning the lottery six weeks running" it may give them a better feel.

One thing that hasn't been considered is what username the botnet is using to Bruteforce. In all the instances I've seen the brute forces have been for variations of admin and root, and in one rare case usernames scraped from the corp website.

I'd also change the interactive login restrictions so that your root account is either disabled (preferred) or restricted to your local subnet or similar address range.

Twice per second is not bad. We used to see thousands of attempts per minute, before implementing fail2ban, which will lock a particular IP out of the network for a set amount of time after so many failed attempts (all configurable).

I agree that changing the password every 10 minutes seems a bit excessive. At this point the problem becomes how do you securely transmit the new password and keep the systems in sync with one another.