Enforce rate limit on authentication attempts

Google's libpam module 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.