[
https://issues.apache.org/jira/browse/GUACAMOLE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham updated GUACAMOLE-990:
-----------------------------
Description:
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.
was:
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 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.
> TOTP Rate Limit To Mitigate Brute Force Security Vulnerability?
> ---------------------------------------------------------------
>
> Key: GUACAMOLE-990
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-990
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-totp
> Affects Versions: 1.1.0
> Reporter: Graham
> Priority: Major
>
> 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)
