24

Obviously some sort of mechanism for limiting login attempts is a security requisite. While I like the concept of an exponentially increasing time between attempts, what I'm not sure of storing the information. I'm also interested in alternative solutions, preferrably not including captchas.

I'm guessing a cookie wouldn't work due to blocking cookies or clearing them automatically, but would sessions work? Or does it have to be stored in a database? Being unaware of what methods can/are being used so I simply don't know what's practical.

Elle H
  • 11,837
  • 7
  • 39
  • 42
  • see also: http://stackoverflow.com/questions/479233/what-is-the-best-distributed-brute-force-countermeasure – Kzqai Jan 06 '11 at 03:37

8 Answers8

22

Use some columns in your users table 'failed_login_attempts' and 'failed_login_time'. The first one increments per failed login, and resets on successful login. The second one allows you to compare the current time with the last failed time.

Your code can use this data in the db to determine how long it waits to lock out users, time between allowed logins etc

alex
  • 479,566
  • 201
  • 878
  • 984
  • 22
    In addition, something I've discovered, you should store failed login attempts for invalid usernames as well. If you only ever lockout failed attempts on valid usernames, then you are revealing which usernames are valid which is a no-no. – Andrew Aug 06 '11 at 14:16
  • 2
    I like storing failures based on two criteria: if a valid user name was used, count a failure for the user name and IP, otherwise just count a failure for the IP. If a specific account is being attacked then it'll lock out the account independent from the specific IP and any single abusive IP gets a site-wide lockout in the process. It is also important to store an explicit expiration time for locks and renew the lock expiration on each attempt. – Jody Bruchon May 19 '15 at 19:10
  • Is there a weakness if the system reveals a login delay (a forced wait after failures) to a user upon presentation of valid username and password? I'm thinking all others, no matter what, should only see "no match for this information." – chrisinmtown Jul 23 '18 at 20:51
  • "If what is needed is blocking the IP, then it would require another table for the IP's" [link](https://www.experts-exchange.com/questions/25477393/php-block-login-for-15-minutes-after-3-failed-attempts.html) – csr-nontol Oct 10 '18 at 05:09
7

Assuming google has done the necessary usability testing (not an unfair assumption) and decided to use captchas , I'd suggest going along with them.

Increasing timeouts is frustrating when I'm a genuine user and have forgotten my password (with so many websites and their associated passwords that happens a lot , especially to me)

Learning
  • 8,029
  • 3
  • 35
  • 46
  • 1
    I agree with this. For *non-essential services* increasing timeouts is incredibly frustrating. – Anand Feb 24 '09 at 05:32
5

Answers in this post prioritize database centered solutions because they provide a structure of records that make auditing and lockout logic convenient.

While the answers here address guessing attacks on individual users, a major concern with this approach is that it leaves the system open to Denial of Service attacks. Any and every request from the world should not trigger database work.

An alternative (or additional) layer of security should be implemented earlier in the req/ res cycle to protect the application and database from performing lock out operations that can be expensive and are unnecessary.

Express-Brute is an excellent example that utilizes Redis caching to filter out malicious requests while allowing honest ones.

ztech
  • 560
  • 5
  • 13
5

Storing attempts in the database is the best solution IMHO since it gives you the auditing records of the security breach attempts. Depending on your application this may or may not be a legal requirement.

By recording all bad attempts you can also gather higher level information, such as if the requests are coming from one IP address (i.e. someone / thing is attempting a brute force attack) so you can block the IP address. This can be VERY usefull information.

Once you have determined a threshold, why not force them to request the email to be sent to their email address (i.e. similar to 'I have forgotten my password'), or you can go for the CAPCHA approach.

Rosstified
  • 4,047
  • 2
  • 25
  • 33
2

You know which userid is being hit, keep a flag and when it reaches a threshold value simply stop accepting anything for that user. But that means you store an extra data value for every user.

I like the concept of an exponentially increasing time between attempts, [...]

Instead of using exponentially increasing time, you could actually have a randomized lag between successive attempts.

Maybe if you explain what technology you are using people here will be able to help with more specific examples.

dirkgently
  • 108,024
  • 16
  • 131
  • 187
2

Lock out Policy is all well and good but there is a balance.

One consideration is to think about the construction of usernames - guessable? Can they be enumerated at all?

I was on an External App Pen Test for a dotcom with an Employee Portal that served Outlook Web Access /Intranet Services, certain Apps. It was easy to enumerate users (the Exec /Management Team on the web site itself, and through the likes of Google, Facebook, LinkedIn etc). Once you got the format of the username logon (firstname then surname entered as a single string) I had the capability to shut 100's of users out due to their 3 strikes and out policy.

Harry
  • 3,031
  • 7
  • 42
  • 67
Noelie Dunne
  • 191
  • 1
  • 2
1

Store the information server-side. This would allow you to also defend against distributed attacks (coming from multiple machines).

Franci Penov
  • 74,861
  • 18
  • 132
  • 169
1

You may like to say block the login for some time say for example, 10 minutes after 3 failure attempts for example. Exponentially increasing time sounds good to me. And yes, store the information at the server side session or database. Database is better. No cookies business as it is easy to manipulate by the user.

You may also want to map such attempts against the client IP adrress as it is quite possible that valid user might get a blocked message while someone else is trying to guess valid user's password with failure attempts.

Real Red.
  • 4,991
  • 8
  • 32
  • 44