PHP: Anti-Flood/Spam system

Question

I'm actually working on a PHP project that will feature a user system (Login,Register,Send lost password to email,..) and I think that this may be very vulnerable to Brute-Force attacks and/or Spam (Send a password to someone's email like 1000 times, etc. use your fantasy) .

• Do today's webservers (Apache, IIS) have some sort of built-in defense against Brute-Force?

• What would be the best way to implement an Anti-Spam/Flood system, if I e.g.: want a page not be able to be called more than two times a minute, however another page may be called up to 100 times a minute or so.

  • I would definitely have to store IP adresses, the time when they last visited a page and the number of visits somewhere - but would it be efficient enough storing it in a text-file/database (MySQL)

  • Should I use captchas for things like registering/recovering lost passwords?

  • Are "text" captchas viable? (Something like "What is 5 plus 9 minus 2? ")

  • The page won't be used by that many users (100-200), do I actually have to implement all these things?

Celiotomy

Answer 1

Regarding CAPTCHAs: I would recommend against using CAPTCHAs unless you really need it. Why?

1. it's ugly.
2. it's annoying for your users. You shouldn't make them jump through hoops to use your site.

There are some alternatives which are very simple, can be very effective and are entirely transparent to _{(almost all)} users.

1. Honeypot fields: add a field to your forms with a common name like "website". Beside it, add a label saying something to the effect of "don't write in this box". Using Javascript hide the input and label. When you receive a form submission, if there's anything in the field, reject the input.

   Users with JS won't see it and will be fine. Users without JS will just have to follow the simple instruction. Spambots will fall for it and reveal themselves.

2. Automatic faux-CAPTCHA: This is similar to the above. Add an input field with a label saying "Write 'Alex'" (for example). Using Javascript (and knowing that most automated spam bots won't be running JS), hide the field and populate it with 'Alex'. If the submitted form doesn't have the magic word there, then ignore it.

   Users with JS won't see it and will be fine. Users without JS will just have to follow the simple instruction. Spambots won't know what to do and you can ignore their input.

This will safeguard you from 99.9% of automated spam bots. What it won't do, even in the slightest, is safeguard you against a targeted attack. Someone could customise their bot to avoid the honeypot or always fill in the correct value.

---

Regarding Brute Force blocking: A server-side solution is the only viable way to do this obviously. For one of my current projects, I implemented a brute force protection system very similar to what you describe. It was based on this Brute Force Protection plugin for CakePHP.

The algorithm is fairly simple, but a little confusing initially.

1. User requests some action (reset password, for example)
2. Run: DELETE * FROM brute_force WHERE expires < NOW()

3. Run:

   SELECT COUNT(*) FROM brute_force 
   WHERE action = 'passwordReset'
   AND ip = <their ip address>
   

4. If the count is greater than X then tell them to wait a while.

5. Otherwise, run:

   INSERT INTO brute_force (ip, action, expires)
   VALUES (<their ip address>, 'passwordReset', NOW() + Y minutes)
   

6. Continue with the reset password function.

This will allow users to only try resetting a password X times in Y minutes. Tweak these values as you see fit. Perhaps 3 resets in 5 minutes? Additionally, you could have different values for each action: for some things (eg: generate a PDF), you might want to restrict it to 10 in 10 minutes.

Seamstress

Answer 2

1. Yes, storing an IP address, last accessed and times accessed in a database would be fine.
2. Using CAPTCHAs for register/recovering password is advised so that e-mail addresses cannot be spammed. Also to stop brute forcing.
3. Yes, text CAPTCHAs are possible, although far easier for someone to crack and write a script to automate the answer. For a free CAPTCHA, I'd recommend Recaptcha.
4. That really depends on how much you care about security. I'd certainly recommend using a CAPTCHA as they are simple to implement.

Theriot

I agree with your #4 response. A limited number of users may use it, but if a spammer/attacker discovers a flaw in the site, they could use any vulnerability they find in the above systems. – Iand

Answer 3

Don't try to implement all the logic in your PHP - the lower in your stack you can implement it, the more efficiently it can be dealt with.

Most firewalls (including iptables on BSD/Linux) have connection throttling. Also, have a look at mod_security for DDOS/brute force attack prevention.

You should design your application around the idea that these kind of attacks will not give the attacker access to the app - at the end of the day there's no way you can prevent a DOS attack, although you can limit its effectiveness.

There's not a lot of value in relying on a consistent IP address from your attacker - there's lots of ways of getting around that.

e.g. keep track of the number of password reset requests between logins by each user. In your password reset form, respond (to the client) in exactly the same way if the user submits an unknown email address. Log invalid email addresses.

HTH

C.

Doerr

Answer 4

Besides doing what Gazler is telling you, you should also have some way of counting the login attempts in general. It the total of all login attempts are bigger then X then either start using the sleep command or just say the servers have a high load.

Shielashield

Answer 5

Storing IP addresses is good practise for loggin and tracking but I think that just a captcha would stop spamming, brute-force attacks and flooding.

Recaptcha is indeed a good solution.

Chatter

Answer 6

sure, Your target audience might not be large but if it's in the public domain then it's vulnerable,

text captcha's are cracked easily these days believe me

for an Anti-Spam/Flood system you could log IP addressses (MySQL preferably) and add a time limit login retries

Boyla