$4K? At what rate? A month? A year?
Is EF still running RedHat Linux? One step would be to run FreeBSD - Linux is fun and all, but the occassional slip up occurs.
FreeBSD hasn't had any issues in ages.
EF has been good and closed off the bulk of the ports, which is smart - at least last I recall checking.
Last I looked (over a year ago if not more), EF (or rather VBulletin) allowed infinite login attempts, ignoring of course bandwith limitations.
The way the passwords work, they are hashed - I think via MD5 if memory serves. So I enter my pass on the client side, it gets passed in (clear text by the way). Then the server takes that and runs it through the hash and compares it to the stored hash - so the system (including admins and the like) never "know" what the password is - just the hash.
Now there is a seemingly huge dataspace available to the hash, but there is also a known issue (unless this has been resolved in the last year or so that I missed out on) where there are a relatively large number of collisions in that dataset.
So that means that it is technically feasible that I have a password of "munchyTits" and then I log in and type a password of "Ilovehotmansex" and it happens to share the same hash and I get in anyway - even with the wrong password.
The liklihood of this happening is obscenely rare though, so it doesn't matter too much for us as EF peeps.
But if someone then set up a program to brute force ever combination of hashes, there are two options. The long way - just create all the combinations of that long string with that character set - or the now shown shorter way - you run through combinations of words and characters into the hash.
That would most certainly get them in, and in less time due to the collisions that occur, so they might not get the right password, but it doesn't matter since they just need the hash.
Stopping that is easy by limiting the attempts at how many times you can get in - again it probably does this now (I hope it does) - but it certainly didn't in the past.
If the passwords fails N times, where N is very small - like 5 - then lock the account and an admin has to unlock it.
That way, it is incredibly unlikely for a brute force attack to function within the space of 5 attempts, but it should be plenty for someone that knows the password to make an error and then say "ahh fuck, I meant to have a 69 at the end of that" and then get in correctly.
I personally think sniffing is overrated. If I can control things on my end, I'm not worried about the colocated side of EF stuff - then again, I also have nothing of value being sent back and forth.
If I did, then I would be worried that my cookie has my password hash right in it.
There was a hole for a bit in IE and in VBulletin that could be combined to get passwords. You could put Javascript code into the IMG tag of VBulletin, that could then redirect a user to another page - on that page you could then strip out the elite cookie and get their username and password.
Then there is the page that is built into VBulletin to restore the admin passwords. Fortunately, EF seems to be smart enough to have htaccess enabled and also not keeping that file around where it is always accessible - either it is deleted as it should be, or renamed something else ideally not easily guessable.
But the fact of the matter is that no matter how hard you really try to lock down a site, you have the same old issues at hand that have always been at hand.
1) dumb users - in this case mods and possibly admins
2) human nature
Between those two, you can get easily guessed passwords (you can work around this by automatically generating them and not allowing the user to pick them), and then there is the fact that everyone will let their guard down to someone - and that someone can walk away with the world if they know what they are doing.
Blah blah blah.
Maybe Code will come in here and make this fun.