Login Throttling (Brute Force Attack Prevention)

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Login Throttling (Brute Force Attack Prevention)

Post by VladSun »

Hm, interesting - nor Wiki for RRD database. The nearest one is http://en.wikipedia.org/wiki/RRDtool
So - it's a fixed size (N records) DB table. Every record after the N-th record my be inserted if and only if the oldest record is deleted, thus the table record count remains constant all the time.
There are 10 types of people in this world, those who understand binary and those who don't
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Login Throttling (Brute Force Attack Prevention)

Post by josh »

That's interesting, sounds like a messy way to handle scheduled pruning though
User avatar
jayshields
DevNet Resident
Posts: 1912
Joined: Mon Aug 22, 2005 12:11 pm
Location: Leeds/Manchester, England

Re: Login Throttling (Brute Force Attack Prevention)

Post by jayshields »

It's basically the system which log files use then.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Login Throttling (Brute Force Attack Prevention)

Post by VladSun »

While these all are kind of data rotators, the RDD is suited to provide data for a predetermined period of time (e.g. the last 24 hours) vs. the "calendar" periods (e.g. data from 00:00 to 23:59) defined in cronjobs/logrotators.

This way we have a "smooth" data changes in RDD vs. a "jumps" of data occurring at the end/begging of the time periods in cronjobs/logrotators.
There are 10 types of people in this world, those who understand binary and those who don't
jason
Site Admin
Posts: 1767
Joined: Thu Apr 18, 2002 3:14 pm
Location: Montreal, CA
Contact:

Re: Login Throttling (Brute Force Attack Prevention)

Post by jason »

I'll stay out of the debate here. I'll focus on something that was briefly mentioned and expand on it a tad.

Don't use a captcha initially. After X attempts on an account, flag the account, and the user via a session/cookie/some form of identifier (IP!) and display a captcha for them. Let them make attempts. As long as the attempts are natural, not too close together, you can assume the user just forgot their password.

After X attempts, let them know that they forgot their password, and highlight the "Recover your password" option. Let them know it's probably faster to recover the password then play the "What's my password for X site" game.

You can also set a log in attempt timer, and prevent more than one log in attempt every Y seconds.

At the same time, you can also send out an email after X attempts to the account holder. Let them know that someone, maybe it's them, is attempting to log in. Hey, if it's them, then provide a link they can use to recover their password. Pro-active is best! If it's not, it let's them know that someone has been trying to get into the site. OH NOES!

I know this gets away from the Throttling side of things (which, I think, if someone is hammering your server, then it's best to handle this at the network end). Of course, if you get a lot of failures across lots of different accounts, you can always just queue log ins. Normal users log in, it queues them up, and logs them in one at a time. Captcha enabled now across the board. Depends on traffic, of course. Again, a lot of this should be handled on the network end. Most of the non-network stuff would be easy to track and implement, and would require tracking of much extra data (stuff you are probably tracking anyways).

Sorry for the top-down approach. I prefer to look at things from a user level first.
User avatar
jayshields
DevNet Resident
Posts: 1912
Joined: Mon Aug 22, 2005 12:11 pm
Location: Leeds/Manchester, England

Re: Login Throttling (Brute Force Attack Prevention)

Post by jayshields »

Thanks for that jason, although I think that kind of solution is overkill for what I am doing. It's still interesting to discuss what would be a perfect login system implementation though.
VladSun wrote:While these all are kind of data rotators, the RDD is suited to provide data for a predetermined period of time (e.g. the last 24 hours) vs. the "calendar" periods (e.g. data from 00:00 to 23:59) defined in cronjobs/logrotators.

This way we have a "smooth" data changes in RDD vs. a "jumps" of data occurring at the end/begging of the time periods in cronjobs/logrotators.
Log rotators I've used don't work like that, you just set a max amount of lines or a max file size and then when the limit is reached the oldest line/record in the log will be deleted before adding a new one. I've never seen a log rotator which would delete everything and then start again - that's just stupid.

Ofcourse proper logging systems (not active rotators) cut off and start afresh (in a new file/table/whatever) whenever they like.

It seems like your comparing RDD as a log rotator and cronjobs/logrotators as proper logging systems.

It might be my terminology for this stuff which is confusing me...
Post Reply