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

Add bruteforce protection to two factor challenge endpoint #2626

Closed
LukasReschke opened this issue Dec 12, 2016 · 4 comments
Closed

Add bruteforce protection to two factor challenge endpoint #2626

LukasReschke opened this issue Dec 12, 2016 · 4 comments

Comments

@LukasReschke
Copy link
Member

We should add the bruteforce protection also the two factor challenge endpoint, there are some challenges with that mainly the fact that we can't just throttle the controller because then a valid token may be expired again.

My proposal would be to basically logout users after 3 invalid Two Factor challenges and increase the bruteforce counter in that case. The user has then to reenter their password and this case will be slowed down.

cc @ChristophWurst @nextcloud/security Thoughts?

@ChristophWurst
Copy link
Member

We've got quite some feedback in nextcloud/twofactor_totp#5 that could be taken into consideration for this 😉

@crispinus2
Copy link

Another thing that should be considered in my opinion is the sequence of challenges. I think it would be better to first ask for the OTP and afterwards ask for the user's password. Additionally, Nextcloud could invalidate the used OTP after one usage, so that an user would have to wait up to 30 secs to reattempt entering his password (or an attacker would have to not only wait 30 seconds to reattempt entering the user's password but also to guess a whole new 6-digit-TOTP).
This process of (T)OTP authentication can be implemented via the corresponding PAM module for e.g. ssh authentication. It makes a lot of sense for me as it prevents any attacker from guessing the user's password or check whether a password he already knows for the corresponding username for another service is also the right one for this service (maybe the attacker already knows it because the user also used it on another service and this service's database had been compromised), because the attacker always has to guess the currently correct TOTP first before trying the real password.
To keep it simple to use I'd suggest to use the input of the password field of the login dialogue as TOTP-key for users which have TOTP enabled and ask for the real login password on the next screen (where the TOTP key is asked as of now).

@doggodanubus
Copy link

I can see a rate limit after four attempts. I'm crippled in my hands and it is damn hard to type. So far the 2FA on Nextcloud works well but I'd hate to see you go the route of my bank where I have 15 seconds left and 45 seconds of typing to do as they do not allow the code slack on timing which sucks. I cannot type a code in 30 seconds depending on what my hands are doing so having the code I'm typing time out is rough.

I can enter it within 60 seconds barely. I can at times make a mistake due to vision problems as well. A fairly good rate limit is to throw up an error and say I need to wait 30 seconds then go back to the login which I have a password manager for and then go back to entering the OTP. However eventually I won't be able to type anything.

And no more than six characters or you've pretty much denied me access. I spoke this and then have to use a grammar checker. Speaking numbers cause some issue or other with Nextcloud and several other sites as I use standalone software for that and it does not work well with numbers.

@nickvergessen
Copy link
Member

Hi @doggodanubus can you open a new issue about that. Commenting on a 5 year old issue is not very helpful at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants