Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login attempts never clear #134

cecilia-donnelly opened this Issue Dec 3, 2015 · 3 comments


None yet
2 participants
Copy link

cecilia-donnelly commented Dec 3, 2015

When a user attempts to log in to the admin site, we log failed attempts in the LoginAttempt table. Then, when the user tries to log in again, we return an error if they've failed to log in too many times. I think this is part of Drywall and we may not want it at all.

If we do want it, then we definitely need to clear the attempts after some length of time. Otherwise, a user who always types his or her password incorrectly and then correctly will find him or herself locked out forever after some number (7, I think) of failures.

@kfogel, do we want to lock accounts after too many failures at all? If so, how often should we clear that table? Once a day?


This comment has been minimized.

Copy link

kfogel commented Dec 3, 2015

I don't think we should lock out after failures; that stopped making sense when large distributed botnets started doing automated login attempts against all public servers, using guessed username/password combinations, on the principle that only a tiny fraction of the attempts need to succeed for the effort to be worthwhile. (See my recent story below.)

We should instead just have a delay between login attempts for the same user, to rate-limit how many attempts can be made for a given user in a given period of time. I think the usual delay is 3 seconds, but somewhere on the Internet there's probably a page with research showing the ideal delay, so see what's out there :-).

Here's that story:

From: Karl Fogel
To: Mailing List Of Various Techie Friends
Subject: Speaking of passwords

I just found out from a rep that the reason Wells Fargo Bank kept
resetting my (incredibly secure) online access password, thus
forcing me to do a password reset dance about twice a month, is that
online accounts get automatically locked after three failed login
attempts.  Since my username was "karlfogel" -- it's changed to
something less guessable now -- some jerk with a botnet was causing
Wells Fargo to lock me out on a regular basis, presumably by trying
a username generated from my real name and passwords that were
various combinations of my birthday, relative's names, etc.  The
same is probably happening to thousands of other customers.  After
all, the hackers only need a tiny number of successes.

I wonder if Wells Fargo has really thought carefully about the
usefulness of a 3-failures lockout policy in the modern era of
distributed attacks against your entire user base.  This was not a
topic I felt it profitable to take up with the phone rep, though.
*cough cough*.

This comment has been minimized.

Copy link
Contributor Author

cecilia-donnelly commented Oct 26, 2016

This came up again today, making this a somewhat higher priority. A user was trying to log in but had reached the maximum number of failed attempts (over the course of the past month) and so the system wouldn't let him in even with the correct password.


This comment has been minimized.

Copy link
Contributor Author

cecilia-donnelly commented Oct 26, 2016

Hey @sbyrne255, welcome! Thanks for offering to look into this. It should be fairly simple to remove the existing restriction. For that part, look in views/login/index.js at the abuseFilter function. Instead of just counting rows in LoginAttempt we want to do something else.

I'm hesitant about 2-step auth, just because it's another hurdle for users. The geographical restriction is definitely interesting, though. Do you want to look into @kfogel's idea about rate-limiting the attempts? Let us know what you come up with!

cecilia-donnelly pushed a commit that referenced this issue Feb 17, 2017

Stop checking login attempts by IP address
All of our login attempts will come from localhost (because we've
configured Node behind Apache).  Therefore, it's not useful to check
whether a given IP address has been hitting us with a lot of requests.
This is somewhat related to #134.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.