Limit authentication attempts?

[Boschman]

I really love this bundle!

I've got a question about the security of the Google Authenticator part of the bundle:

Wouldn't it be necessary to limit the authentication attempts? I know every code is only valid for 30 seconds, but that doesn't totally rule out a brute force attack.

What's your take on this? And how to handle with this issue?

[scheb]

Currently there is no limit implemented. If you want to contribute, feel free to create a pull request.

[Spomky]

This feature is really important for security.
As explained un this blog post (approx translation hereafter):

Let TOTP code consists of 6 digits - is 1,000,000 options. And even allowed to enter the code 1 in 1 second and 30 seconds the code lives.

The chance that in 30 attempts in 30 seconds to guess the code - 3/100000 ~ 0.003%. It would seem a little. However, these 30-second windows in the day - 2880 pieces. Total, we guess code probability (even though it is changing) = 1 - (1 - 3/100000) ~ 2880 ~ 8.2%. 10 days of such attempts are already yielding 57.8% success rate. 28 days - 91% success rate.

So we must clearly recognize that you need to implement at least one (and preferably both) of the measures proposed by the authors of the standard.

The both measures are:

• Track the number of unsuccessful attempts to enter the code, and the ability to block the authentication exceed a certain maximum limit. Limit offer to do so small as to be more comfortable to use the service.
• Set delay after a failed entry attempts. And to increase the delay linearly with the number of failed attempts. For example, after the first attempt - setting the delay is 5 seconds, after the second 10 etc ..

[Boschman]

Thank you both for your replies! And a great explanation of the security risks, @Spomky!

If you want to contribute, feel free to create a pull request.

I would like to contribute. Perhaps you two can help with thinking about the ideal solution?

What would be the best way to save the failed attempts? What about adding two fields to the user entity?

• failed attempts counter (integer)
• last failed attempt (timestamp)

And would it be secure to just empty these fields as soon as there is a successful attempt?

[scheb]

That would definitely be the proper solution. I also thought about storing the data in the session, but then an attacker which has username/password could just drop the session and start from scratch. So there is no alternative to persisting the information somewhere.

[frak]

I know that this is an old thread, but surely it would be easier to use fail2ban's existing functionality? It even comes with a handy Symfony bundle

[Boschman]

Thank you for your reply!

I'm not really familiar with fail2ban. Could you describe how this would provide a solution for this problem?

[frak]

From the fail2ban website:

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc.

The plugin that is linked to details how to configure this service to work with Symfony applications, although I am pretty certain that extra work will be needed to factor in this bundle.

[Boschman]

Sounds like an interesting solution. But something to keep in mind regarding the user experience: multiple failed attempts are not necessarily hack attempts. It might be a valid user that just isn't able to produce the right Google Authenticator code (for whatever reason). Just shutting those users out by completely blocking their IP is probably not what you want. Suddenly they won't be able to reach the website, without knowing what's going on. A decent error message is much more user friendly, in my opinion.

Also: when there's (for instance) a company operating from one IP address multiple failed attempts might come from different users. So you might shut out a whole company when just a few users have trouble producing the right Google Authenticator code. I don't think fail2ban will be able to distinguish those different users?

What's your take on this?

[scheb]

The upcoming 3.0 version provides hooks to implement anti brute-force. See the docs: https://github.com/scheb/two-factor-bundle/blob/master/Resources/doc/brute_force_protection.md