views:

147

answers:

5

I'm trying to write an improved password reset function for one of our public facing websites and in addition to a better captcha I wanted to flag a username that attempts to login w/ no success x amount of times in under y minutes. The first thought was to have a database that logs each attempt and then after the max amount of attempts in the time - we simply lock the account until a phone call is recieved from the employee's manager to reset it.

What is a better approach that doesn't require persistence via SQL. (Cookie/something else?) If one does not exist, how can I do this with a cleaner approach? for some reason my brain is full today

+3  A: 

Check this answer about Throttling them.
http://stackoverflow.com/questions/570160/throttling-login-attempts

Jeff Atwood has an interesting blog post about the subject in case you're curious.
http://www.codinghorror.com/blog/archives/001206.html

Storing them in a database can get tedious, and you will end up worrying about flooding your table with failed login attempts. Also, storing something on the user's machine that controls this is also tricky because they have control over all of the files on their machine, and they could easily reset your failed login counter, or worse, send you faulty/malicious data back.

Robert Greiner
+1  A: 

Using cookies or sessions would be bad, since a user could clear their login attempts by just clearing out cookies. Maybe using a file in a temp directory to store the login attempts would be appropriate?

Eric Petroelje
+1  A: 

Well a cookie is not useful against an attacker (they'll just remove the cookie or just not send it to you). If you have in-memory application state, you might be able to use that, but ou have to be really careful, as doing that might cause you to fill up your memory really quickly, in addition to running into scalability issues due to concurrency and locking. And even this might not work on an app that's running on many different servers, as that application state probably is not shared between those servers. Why do you think storing data in the database is a bad idea?

Yuliy
I don't think storing this data in SQL is bad, i just wanted to avoid the database addition ... but if required (as it appears to be) - then I will take the time to do this right
Toran Billups
+1  A: 

You could use a database, use memcache and setup a cron job to dump the table periodically. You also could use cookies or session variables but I wouldn't rely on these for security reasons.

Jason Rikard
+1  A: 

Be aware that the goal of a cracker might not be to gain access to your system, but to make it unusable for everyone. He could maybe achieve this by willingly logging in with false credentials to block certain users from your site! I think you won't find any adequate solution without a database.

merkuro