[ https://issues.apache.org/jira/browse/GUACAMOLE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834022#comment-17834022 ]
Mike Jumper commented on GUACAMOLE-990: --------------------------------------- Yep, that's correct. I don't recall whether we already added Docker environment variables around the new extension's properties, but perhaps now would be a good time to switch things around and leverage {{enable-environment-properties}} to avoid having to manually update the images every time new properties are added. I made some experimental changes implementing that, and it seems to work well (and deletes a bunch of code). > Enforce rate limit on authentication attempts > --------------------------------------------- > > Key: GUACAMOLE-990 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-990 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-totp > Reporter: Graham > Assignee: Mike Jumper > Priority: Trivial > Fix For: 1.6.0 > > > 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.20.10#820010)