Skip to content

TOTP/30 Second Requirement Revisited #1600

@AlexThurston

Description

@AlexThurston

Hey Team. I've brought this up before over the years but thought it was worth potentially revisiting the question just in case there was an opportunity to have it changed (since it came up recently for us).

The question is about the 30 second restriction implemented for TOTP. For normal API use, this isn't a problem. The problem arises with test session token refreshing.

We have many projects involving ACVP within the organization. We've built some pretty powerful tooling around the managements of these projects which allows for some real efficiency and modernization in the interaction.

These projects often have a number of test sessions that have been created on both demo and production. As we navigate the system, those test sessions are read ad interacted with. In cases where the access token(s) for the test session(s) have expired - we use the batch refresh API to get new ones which is useful.

However, given our user-base is growing, this needs to happen for different groups of test sessions a lot more often. In the simplest example, two users refresh their project's list of test sessions, the first uses a TOTP to batch update theirs, but the other users needs to wait 30 seconds before they can update theirs. And this is an example where there only 2 users. We've got many more than that so the problem becomes quite pervasive.

Is there anything that can be done to perhaps give us the ability to be more performant in that area.

Here are some ideas.

  1. Remove the restriction on the TOTP that it can be used multiple times in the 30 second window and then needs to be updated. I know this means that it is no longer a ONE-TIME password, but at least it will only be usable for 30 seconds at a time before requiring to generate a new one.
  2. Allow the TOTP to be used to multiple times only when refreshing test session access tokens only.
  3. (Preferred solution) Remove the expiration of test session access tokens entirely. Given these access tokens only give you access to test session interactions and nothing else, so I don't see this as much of a security risk.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions