#2986 Allow TIMEOTP placeholder to generate the next TOTP when close to expiration

[Santiago González]

It would be useful if the {TIMEOTP} placeholder accepted an optional integer parameter (milliseconds) to indicate a minimum remaining validity threshold before generating the current code.

Example:

{TIMEOTP} → current behavior

{TIMEOTP:3000} → if the current TOTP has less than 3000 ms remaining, generate the next TOTP instead

Example behavior:

• TOTP duration: 30 seconds
• Remaining validity at generation time: 2000 ms
• Placeholder: {TIMEOTP:3000}

Expected result: KeePass generates the next TOTP instead of the current one.

This is particularly useful for websites or identity providers that are strict about TOTP validation and expect the currently valid code with little or no tolerance for clock drift or near-expiration submissions.

It is also helpful in Auto-Type workflows where the TOTP is not typed directly into the page, but copied to the clipboard for manual paste due to the website UX flow. In some login experiences, the OTP field is only available after authentication or after a delayed page transition, making it impractical to type the TOTP immediately as part of Auto-Type. By the time the user pastes the copied TOTP, the current code may already be close to expiration or invalid.

This feature would improve reliability while remaining fully backward compatible, as the parameter could be optional and default to the current behavior.

I understand that a similar effect can be approximated by adding a delay before copying the TOTP in an Auto-Type sequence, but this is not an exact solution.

A delay-based workaround introduces timing uncertainty: the user could manually paste before the TOTP is copied, accidentally pasting a previous clipboard value instead. Additionally, while delaying generation may reduce the likelihood of expiration, it does not guarantee that the pasted TOTP will still be valid at paste time.

Finally, it also makes Auto-Type sequences less clean and elegant, as timing concerns need to be manually encoded into the workflow instead of being handled directly by the TOTP placeholder itself.

[wellread1]

Which sites are you aware of that "are strict about TOTP validation" and how strict are they?

The TOTP: Time-Based One-Time Password Algorithm RFC6238 strongly recommends the use of a "number of time steps a prover can be "out of synch" before being rejected". For the recommended 30 second step the RFC recommends a two-step backward. This results in an approx 89 sec interval during which a recently generated a 30 second TOTP will be valid. This seems quite adequate. I have never experienced a problem with TOTPs expiring. If it does expire you can almost always generate a new TOTP. The usual error I experience is copy and pasting the wrong TOTP.

Since the common implementation of TOTPs provides an adequate time interval for acceptance I don't see the need for this feature.

[Paul]

Placeholders are filled at time of use and trying to replace them at some later time may be fraught with difficulty becasue KeePass doesn't know where you are using them, so may not be able to update them.

FWIW, I have never had a TOTP fails because I was too slow to use it, and you can Auto-Type the TOTP at a later time if you have been particualrly tardy (assuming the site you are using also updates the TOTP).

cheers, Paul

[Santiago González]

Thanks for the feedback.

I agree that RFC6238 recommends tolerance windows and that many implementations are forgiving in practice. However, the RFC recommendation is not mandatory, and real-world implementations vary. Some services appear to accept only the currently valid code or behave more strictly near the boundary of a time step (whether by implementation choice, clock skew handling, or simply imperfect implementations).

In my own experience, I have encountered this with at least some government services and at least one other website that I unfortunately do not remember. I appreciate that this may not be common, but it does happen in practice.

My request is not based on TOTP expiration due to being slow to type. The issue arises in Auto-Type workflows where {TIMEOTP} is generated at one moment, but intentionally used later.

For example:

1. Username/password are submitted.
2. A page transition or MFA step occurs.
3. {TIMEOTP} is copied to the clipboard.
4. The user manually pastes it once the OTP field becomes available.

In this workflow, KeePass already resolves the placeholder at time of use, but the actual use of the TOTP may occur seconds later due to website UX constraints.

I understand that a delay before {TIMEOTP} can partially mitigate this, but delays are heuristic rather than deterministic. They also introduce tradeoffs (e.g., clipboard timing and potentially still landing close to expiration).

The suggestion is intentionally small and opt-in:

{TIMEOTP} → current behavior

{TIMEOTP:3000} → if less than 3000 ms remain, generate the next code

No behavior changes for existing users, and it would simply provide a more deterministic option for timing-sensitive Auto-Type workflows.

[wellread1]

Failure of an auto-type sequence that is the result of a site's poor choice of TOTP validity duration strikes me an extremely rare edge case. Testimonial evidence that this not the case is unconvincing. As you have mentioned in your post, it is already possible to design KeePass auto-type sequences that overcome this type of problem. I recommend you use those methods.