Bug 5614 - document ThinLinc limitations with TOTP (and possibly HOTP)
Summary: document ThinLinc limitations with TOTP (and possibly HOTP)
Status: CLOSED WORKSFORME
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Documentation (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.11.0
Assignee: Samuel Mannehed
URL:
Keywords:
: 7000 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-08-25 13:47 CEST by Pierre Ossman
Modified: 2019-10-15 13:04 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2015-08-25 13:47:37 CEST
Split from bug 5608:

When it comes to alternatives, it's worth noting that our requirement is using
the OTP twice: One time against the master, one time against the agent. Many
TOTP implementations allows this. This includes google-authenticator. It allows
a "DISALLOW_REUSE" paramter in the config, but apparently it's not there by
default. Also, according to this Twitter post, many other implementations also
accepts the OTP multiple times:

https://twitter.com/jmedwards/status/558561104214102016

"Amazing how many vendors allow reuse of TOTP/2FA codes within time window.
Culprits: most banks, Github… At least Google follows the RFC."

The RFC does indeed not allow multiple use of the OTP:

https://tools.ietf.org/html/rfc6238:

   Note that a prover may send the same OTP inside a given time-step
   window multiple times to a verifier.  The verifier MUST NOT accept
   the second attempt of the OTP after the successful validation has
   been issued for the first OTP, which ensures one-time only use of an
   OTP.
Comment 1 Pierre Ossman cendio 2017-08-14 13:37:37 CEST
*** Bug 7000 has been marked as a duplicate of this bug. ***
Comment 2 Pierre Ossman cendio 2019-10-15 13:03:49 CEST
Our documentation states that we require:

>     An OTP server which accepts the OTP twice. This is due to the ThinLinc architecture: The client first contacts the master machine, and then the agent host. When using RSA SecurID, we recommend using the Steel-Belted Radius server as a "Token Caching Server".

Note You need to log in before you can comment on or make changes to this bug.