[
https://issues.apache.org/jira/browse/GUACAMOLE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061384#comment-17061384
]
Graham commented on GUACAMOLE-990:
----------------------------------
My 233 napkin math was with the assumption that an attacker would script out an
attempt to hammer the totp input dialog as quickly as could be driven by their
internet latency per attempt (7ms for instance), so 30 seconds * 1000 =
30000ms. 30000/7=4285 attempts per 30 seconds. And then 1000000/4285=~233 (on
average of course...luck of the draw).
fail2ban would definitely work in terms of banning a single IP attacker trying
to break the initial password (assuming it wasn't a spray attack and all), but
does guacamole log something separately for a failure during the totp phase? In
syslog all I see on each successive attempt to enter an incorrect totp code in
syslog is the following:
tomcat9[1805]: 04:14:08.569 [http-nio-8080-exec-7] INFO
o.a.g.r.auth.AuthenticationService - User "username" successfully authenticated
from <IP>
I did try enabling debug logging via logback.xml, and I get a huge number of
pages on each attempt, but when I filter by my IP I still just get the above
along with some "UserRecordMapper.insert" which seems to just be recording a
timestamp.
I guess perhaps I could set up fail2ban to ban based on too many successive
_successes_ in a certain time period...might give that a shot tomorrow. It'd be
nice if there was a distinct failure message in the log for the totp attempts
though.
Another idea I had was perhaps trying rate limiting via an nginx proxy.
> 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)
