A CAPTCHA is an image that is (ideally) impossible for a computer to read but easy for a human. It's used to verify that a user is not a bot, rendering brute-force attacks unfeasible. However, even if it is easy for a human, it's also very annoying. For that reason, you need to use them with moderation.
The biggest technical threat is brute-force attacks on account logins. If someone gets the password of the admin account... well, I don't have to tell you the kind of hurt that can result. Combating this can be as simple as implementing brief (15-minute) bans after a certain number of failed login attempts. I don't think it's feasible to use CAPTCHA in this case because it's something that everyone will be presented with, especially if they don't have their browsers set to keep them logged in. I dislike entering more than a couple of them a day, and any unnecessary ones annoy me. However, if you implement temporary IP bans and change your password regularly, it should afford you a reasonable amount of protection. Other options here may be to require CAPTCHA on all attempts after the first one (decided by IP, not cookie), or to create an account that is used only for administration and give lower permissions to your regular account.
You can use CAPTCHA on registration, but I don't like to spend too long filling out registration forms, either. Besides, a human can register, then let a bot loose on the site. It's still not a great solution, although if you have fairly generic registration forms (or use an unmodified script), that may be a concern.
Instead, I suggest requiring CAPTCHA on a user's first few posts/comments/messages. After the first few, no more annoyances. One idea I just came up with and have yet to implement is simply to require CAPTCHA for all users with a 0/0 ratio. If you're using your account, you're likely not a bot.
No matter how careful you are, some will inevitably slip through. As I've mentioned before, proactively promoting moderators means that what does get through can be dealt with reasonably quickly. This is especially nice in the case of porn spam with images attached, which is never nice to be presented with unexpectedly.
If you have any other suggestions, I'd love to hear them.
7 comments:
Just to add to your 'multiple login attempts' advice, I'd suggest that you lock those specific accounts temporarily, in addition to an IP ban.
The reason is quite simple: a sophisticated attacker is going to be tied to neither his IP address nor his cookies (as you've already pointed out). Therefore, the safest route is generally to temporarily lock out the entire account.
If the legitimate user comes along, they may be locked out, but they will also be alerted to the fact that someone is trying to access their account, and handle it accordingly.
Note that the IP ban is still important, as without it you give an attacker an easy way to lock everyone out their accounts.
Further to this, you should provide a mechanism through a separate interface that allows you to unlock all accounts. You should also be logging all 3-attempt failures, and start perma-banning the IP addresses which appear more than a couple of times.
I'm not a fan of perma-bans. I use Tor for all my related activity, and I know a number of nodes have been banned due to abuse. Understandable, but I sometimes need to change identities multiple times before finding an IP that I can use.
Similarly, I don't know that locking accounts is helpful. If an attacker is trying to access a particular account, yes, but there's nothing to prevent them from making attacks on multiple accounts in sequence if they're simply looking for a way in.
Another possible consideration would be a potential attack via cookies. I don't know how common this is, but an attacker could conceivably repeatedly send cookies with different passwords/sessions until they find one that the site will accept. Preventing this may be a little more involved.
I can understand why you might be against perma-bans. In fact truly permanent bans are rarely useful, because eventually they will become redundant or ineffective. Generally for perma-bans you should substitute in a time period which is sufficiently long to deter the trolls and sufficiently long to make brute forcing a password infeasible. This might be a day, week, month or year.
I politely disagree with your comments on locking, though. Even an attacker who hits many accounts in an attempt to break in will be effectively stopped by account locking. Unless of course each of your users has the same password, in which case you've got a much bigger security problem at hand. If you're worried about the legitimate user being inconvenienced, you could always send them an automatically generated email with a url containing a unique 'unlock code' which they can use.
As for the cookie situation, I think the best solution is to use two cookies. The first one is your session cookie, which for most people will be the default PHPSESSID cookie. For most people the security of this cookie lies in the statistical improbability of picking the same random number as another person in a very large key space. If this isn't enough for you, you could easily override the default session cookie and cryptographically tie the session id to the username and password (e.g. COOKIE{ sessionid, hash(sessionid, uname, password) } ). The session cookie becomes reasonably secure, because the sessionid changes regularly. The second cookie is your semi-permanent cookie, which may equate to a 'Remember Me' checkbox on your login. If a session cookie is not available you can fall back to this cookie. However, you should treat authentication through this cookie as a log in attempt and apply the same restrictions and safeguards as your standard login screen.
-Nick
I think I know who you are finally!
Well that's all manner of creepy...
Undoubtedly.
Post a Comment