Page 2 of 2
Re: Login Throttling (Brute Force Attack Prevention)
Posted: Fri Dec 04, 2009 1:04 pm
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.
Re: Login Throttling (Brute Force Attack Prevention)
Posted: Fri Dec 04, 2009 5:53 pm
by josh
That's interesting, sounds like a messy way to handle scheduled pruning though
Re: Login Throttling (Brute Force Attack Prevention)
Posted: Wed Dec 30, 2009 6:35 am
by jayshields
It's basically the system which log files use then.
Re: Login Throttling (Brute Force Attack Prevention)
Posted: Wed Dec 30, 2009 8:11 am
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.
Re: Login Throttling (Brute Force Attack Prevention)
Posted: Wed Dec 30, 2009 8:29 am
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.
Re: Login Throttling (Brute Force Attack Prevention)
Posted: Wed Dec 30, 2009 10:12 am
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...