[
https://issues.apache.org/jira/browse/GUACAMOLE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061321#comment-17061321
]
Mike Jumper commented on GUACAMOLE-990:
---------------------------------------
No, there is no built-in rate limiting around authentication. I would suggest
deploying something like fail2ban if you wish to ensure brute force attempts
are quickly squashed.
I definitely don't think that math is correct (with 1 million possible codes,
you'd expect the odds of a correct guess to be 1 in 1 million, not 1 in 233),
and you would have a rather limited amount of time in which to make those
million guesses before the code changes, but it's not an
unreasonable feature.
It may be possible to do this across the board at the webapp level, temporarily
blocking auth requests from that particular IP if some threshold has been
reached, however you can definitely already do that with fail2ban.
> Enforce rate limit within TOTP
> ------------------------------
>
> Key: GUACAMOLE-990
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-990
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-totp
> Reporter: Graham
> Priority: Trivial
>
> Google's [libpam
> module|https://github.com/google/google-authenticator-libpam/blob/master/man/google-authenticator.1.md]
> has a rate limit option to prevent brute forcing.
> Does Guacamole's TOTP have anything built-in that's introducing any
> sleep/delay in the code input loop?
> It _seems_ like it doesn't from my clumsy attempts at testing this by just
> hammering the keyboard :)
> If that's true then it seems like this would potentially be easier to bypass
> than even the password itself. I might be butchering the napkin math here,
> but with a possible number range of 1 million (6 digits) and 30 seconds,
> assuming a WAN latency per attempt of 7ms, that would mean that on average,
> once a hacker broke a password, they could then break through the TOTP
> segment over a scripted 233 login attempts or so.
> If there was even a plain old unconfigurable 1 second sleep/delay (or better
> yet, a continually increasing delay of n*1second based on past failure count
> in the current cycle) built in to the code input loop between attempts
> without even any added guacamole.properties options being introduced, I think
> this would basically handle the problem by pushing the possible average
> breakthrough time into unreasonable timelines.
> Also, though this would be another issue, it seemed that incrementing
> totp-digits with v1.1.0 to 8 didn't result in 8 digits being displayed when I
> scanned the resulting barcode in google authenticator. The introductory user
> bit did specify 8 digits - just not the resulting google authenticator entry.
> That may just be a bug in google authenticator however - not sure as I
> haven't tested any other TOTP apps, but I thought I'd mention it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
