How to PROPERLY Secure Your vBulletin Forum

After spending a couple of hours on a post, I inadvertently forgot to:

1. Copy my work
2. Log back in
3. Recreate the title
4. Post my work

However, no message forum user should ever have to remember to follow these four steps during a single session. Unfortunately, since one of my favorite message forum’s installation of vBulletin does not preserve the post (it does on most other vBulletin forums, including my own), the inevitable result is that the post (and my time) is lost.  A user’s long, hard work winds up being met with the following message, along with the complete loss of his or her work:

vBulletin Login Timeout

Therefore, I’m going to ask them again to please change the timeout from its current setting.

Here’s why: Overly short timeouts are the least effective way to increase forum security. By changing other parameters, you can make your forum many millions of times more secure than by greatly inconveniencing users with puny timeouts.


Only slightly complicating this problem is the fact that there are two issues at work. Actually, there are many, but given what the admins can quickly and easily change, it only involves two issues: Brute-force attacks and man-in-the-middle attacks. The login timeout involves man-in-the-middle attacks. Put simply, while you’re logged in, someone listening in to the data transmissions between your computer and the forum’s servers can easily locate the session key. However, that’s useless to them unless they’re able to crack it while the session key is in play, then use it to log into using the sniffed user’s account, and change their password, e-mail information, etc.

All that nets them, however, is that individual user’s login credentials. It cannot hack the system itself. Furthermore, even the guest session uses a 32 character session hash. Given 96 available characters, that’s a keyspace of 2.70819E+63. In case you’re wondering, and according to Steve Gibson of Gibson Research Corporation, it would take a massive cracking array capable of one hundred trillion guesses per second at least 6.22 thousand trillion trillion trillion centuries to exhaust this session hash. If one wanted to be 99.9999% certain it couldn’t be found, then it would still take 6.22 billion trillion trillion centuries to crack.

Not only is that an extremely long time, more than a trillion trillion times longer than the age of the entire universe, it’s also the reason why maintaining a short login time is not merely petty, but it’s pathetic, as well.

Let’s work through some examples to see how this works:

– Login timeout: 20 min
– Min password length: 7 characters
– Max number of retries: 5
– Retry lockout: 15 minutes

Example 1: Change login timeout to 10 min

Result: This halves the time a man-in-the-middle attack can intercept a login. However, these attacks are only good during that particular session. Unless the attack cuts off communication with the user, the moment that user logs off, that key is cleared and the attack is halted. In the meantime, users are greatly inconvenienced by constantly being booted off the server every time they grab a lock snack, make dinner, or are busy working on a long post.

Result: It only makes the bad guys work twice as hard.

Bottom line: Login timeouts are so pathetically and ridiculously ineffective (see the 6.22 trillion trillion trillion centuries explanation above) that it’s best to set them to 12 hours, if not 24 hours, and use other, far, far, far more effective means as described below:

Example 2: Change the min password length to 8 characters.

Result: Since 96 characters are available for passwords, this makes the bad guys work 96 times harder. That’s 48 times more effective than halving the login timeout.

Bottom line: Increase the min password length to 8, thereby gaining 48 times more effectiveness in deterring a brute-force attack.

Speaking of passwords, you can also enforce a ban on dictionary passwords and/or the use of at least one each of upper, lower, numbers, and special characters. That results in an increase in security of between several thousand-fold to trillions.

Example 3: Reduce the max number of retries to 2 (total of 3 tries)

Result: This halves the number of times a brute-force approach can crack the password. However, if the min password length is set to 7, that’s 75,144,747,810,816 possible passwords. Thus, instead of giving them 6 chances to work miracles, you’re giving them 3 chances to work miracles. Regardless, merely by using reasonable values for the max retries and retry lockout, you’ve already defeated the brute force approach, completely.

Bottom line: It’s better to leave it at 5 retries.

Example 4: Increase the Retry Lockout to 30 minutes.

Result: This just ticks people off. The whole point of combining the use of the min password retries and retry lock out is to limit the long-term ability of anyone to brute-force attack any particular user’s login.

Bottom line: Leave it at 15 minutes.

With 5 total tries and a retry delay of 15 minutes, you’re limiting the system to a maximum of 20 tries per hour, or 480 tries in a 24-hour period. Compared to 75,144,747,810,816 possible passwords, that’s nothing. Well, actually, it’s next to nothing. Specifically, it’s 6.387671e-12. Put another way, you’re at least 99.999999999361% “safe.” However, that’s simply by combining an attempt limit and retry lockout with an 8 character password minimum. Those who use a 9 or 10 char password receive 96 to 9,216 times more protection.

With all of the above in mind, here’s an expert vBulletin administrator’s advice:

Recommended Settings:

– Login timeout: 24 hours (1,440 min)
– Min password length: 8 characters
– Enforce no dictionary words: Yes
– Enforce the use of upper, lower, numbers, and special chars: No
– Max number of retries before lockout: 3
– Retry lockout: 5 minutes

Now, if you’d like to double the trillion trillion trillion centuries (or more) level of protection afforded with the settings above, for just $18 a year, you can Convert Your vBulletin Installation to HTTPS (SSL/TLS).