1

I'm having problems to fully understand how to prevent rapid-fire login attempts. My questions basically come from the The definitive guide to form-based website authentication.

The final recommendation is setting a login throttling, setting a time delay between failed attempts. Something as:

  • 1 failed attempt = 5 sec delay
  • 2 failed attempts = 15 sec delay
  • 3+ failed attempts = 45 sec delay

A few questions that easily come to mind are:

  • If we're trying to protect our system from brute-force or dictionary attacks, how is it that the delays are so restrictive?. One of the examples shows an increase of 2**2 per invalid attempt. Wouldn't a fairly minor amount of time discourage already an automated attacker?.

  • In this protection scheme, what would be the client? How would it be identified?. Are we talking about an IP+account or just account?. If we are talking about just an account without taking into account the IP, isn't that likely to bother legitimate users trying to access their account?.

  • I have never seen any reading material talking about humans trying to access accounts?. I understand that this case would be highly unlikely (more if we assume password policies in place) but, what if an attacker has built a list of likely passwords via some method (social engineering). Shouldn't that be protected too?. Because in that case, and being the client identified by IP+account, being very restrictive would make a lot of sense, trying to block the IP that he is using.

  • How does throttling failed logins make a real difference between just simple throttling?. With simple throttling, I mean a throttle over the 'login' endpoint that controls the number of times that you try to log-in, but without taking into account if these attempts were successful or not.

Assuming this previous definition for what I meant with a simple throttle, let's assume that I am controlling the number of times that you can call the login endpoint for one account given a span of time:

  • For each account, the login endpoint can be called 3 times each minute.

Would that be enough to stop a brute force attack?. Does adding this delay mentioned before when the attempt is invalid yield better results?.

I would be super grateful if anyone could shed some light here.

  • 45 seconds delay after 3 failed attempts is restrictive? That looks very permissive to me when many sites lock the account after 5 failures. – schroeder May 18 '17 at 12:59
  • is your 3rd point a question? I'm not seeing anything to respond to there. – schroeder May 18 '17 at 13:02
  • @schroeder, very appreciated your comments. With restrictive, I meant a sequence that appears also in the guide, (2,4,8,16,256). I had assumed that smaller times would already make things complicated to the automated process, but as you pointed out in your answer that might not be the case. I'll comment about my definition of simple throttling in your answer. – IoChaos May 18 '17 at 13:16
  • I think delays should be nonexistent up to 5 attempts and then then the account is locked. That way users aren't annoyed and bots will stay away. – Awn May 18 '17 at 13:37
  • how are you planning on server throttling without crippling your server? – Neil McGuigan May 18 '17 at 16:12
2

The main idea here is to quickly slow down the window for brute-forcing an attack. You normally implement this like:

  • Track on an account base. (so each account has its own wait time)
  • Increase the wait time exponentially.
  • Have an reset mechanism for the password and or wait time through some person (Admin / service desk / etc.)

The main difference between normal throttling and the login throttle is the wait time mechanism. the exponential factor means that you quickly have to wait for more than a day per password entry (effectively blocking that account), making detection of abuse much more likely, and normal throtteling you count connections / throughput per time, and have a stable amount of allowed actions in each slot. (so its a constant rate of attempts instead of a quickly diminishing amount).

  • Thanks @LvB, I'm starting to see the point :). Can you please confirm then that this exponential factor should affect to the account without taking into account the IP where the request is coming from?. So a legitimate user could try to use the account and he/she should have to wait or contact service desk due to the requests made from other location?. – IoChaos May 18 '17 at 13:31
  • It's only that I see it implied (in your answer and guide), but I don't think I have ever used a service where that situation happened to me. Initially, I understood that the client was defined as IP+account. – IoChaos May 18 '17 at 13:35
  • 1
    Yes, thats the idea. its being actively used in some LDAP / KERBEROS implementations and I know that FritzBox! uses it when logging in. Also the iPhone has this in place (as a non web implementation). Normally as a legitimate user you do not see this. (unless you forgot your password) – LvB May 18 '17 at 14:12
1

If the attacker is automated, then they are ok with waiting. They might let their tool run for a long time, if you let them. So, they will not get 'discouraged' easily (that's what tools are for).

Locking accounts does have a user experience impact, and each site needs to run that risk analysis. How you define the 'client' is up to your specific scenario.

  • 2
    Throttling is still a problem for running a brute-force attack. Your tool will need far longer to guess a password when it is limited to one request every 45 seconds. This gives more time to the admin to notice the attack and blacklist the attacker's IP (although there is fail2ban to automatize that). – Philipp May 18 '17 at 13:05
  • @Philipp of course, but that requires a certain set of conditions to exist. If there is a 45 second delay, would the admin notice? (no load). Would they care? – schroeder May 18 '17 at 13:11
0

A 'smart' attacker does not attack a single account, but tries common passwords for a wide range of user accounts.

So, if you want to defend against a rapid-fire-login-attempt attack, increasing the delay for a single account does little to protect the system as a whole.

I suggest keeping a running average of failed login attempts for the system, within a certain time limit (5 minutes for example). If the number of failed login attempts for the system start to spike, compared to the running average, you delay the login attempt feedback for all login attempts system wide.

The weight of the delay can be tuned to match the difference between the running average and the measured spike.

Once a delay has been triggered, the running average can no longer be trusted, because it is now (potentially) influenced by the attacker. So you need to come up with some other method to decide when to decrease or stop the delay in login attempt feedback.

0

You have to consider the intents of the unauthorized access. For someone, it could be to gain access to the account in order to obtain the information within. For someone else, it could be to deny the rightful owner access and use of the account. For yet another person, it could be to initiate an effective denial of service attack on a service that would otherwise shut down the packet storm or LOIC attack upstream.

IT security is not only about denying bad actors access to information, but about ensuring the authorized users have reliable and dependable access to their information.

For want of a nail... all was lost.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.