Skip to content

Is a time-based token a security concern (timing adjustable) #1424

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ajanec01 opened this issue Sep 17, 2020 · 3 comments · May be fixed by #4382
Open

Is a time-based token a security concern (timing adjustable) #1424

ajanec01 opened this issue Sep 17, 2020 · 3 comments · May be fixed by #4382

Comments

@ajanec01
Copy link

Hi

Can you please clarify what is meant by "security concerns" in the context of timing adjustable? More specifically, is there a difference between security concerns set by the content and a 2-step authentication that relies on time-based tokens?

The "Notes regarding server time limits" section in the understanding doc for 2.2.1 says:

This Success Criterion applies only to time limits that are set by the content itself. For example, if a time limit is included to address security concerns, it would be considered to have been set by the content because it is designed to be part of the presentation and interaction experience for that content.

To illustrate where I get confused imagine a scenario where after the login page, the user needs to authenticate again by providing a code that is sent to the user's mobile phone. A token is generated, and it's valid only for a few minutes. If the user doesn't enter the correct code within the time limit, then the next click on any UI component redirects the user to the login page, and the process starts again (the token expires). There is no chance to either turn off, adjust or extend the session.

As I currently understand it, the understanding doc for timing adjustable seems to say that it is a failure because the time-based token is automatically generated, and it was implemented due to security concerns. However, there is an argument to be made that it is essential because extending it would invalidate the activity.

It doesn't help that examples of this issue do not seem to be consistent. In the understanding doc for re-authentication, the example of a questionnaire does not seem to meet any of the requirements of timing adjustable and it's referring to re-authenticating. It makes me believe that there is a difference between security concerns and authentication.

Is not being able to extend, adjust, or turn off the time limit of the time-based token used for 2-step authentication failure of the timing adjustable criterion?

Clarity on this issue would be much appreciated!

Many thanks
aron

@tilensA11Y
Copy link

Is there any solution to this question?

@patrickhlauke
Copy link
Member

for timing adjustable, i'd say the time-based token falls under the essential exception, as it's essential for the security of the app that the token doesn't last indefinitely / for an overly long time. it might be worth mentioning this in a note on the timing adjustable understanding.

as for the re-authentication examples, some of these do seem to edge close to failures of timing adjustable. it may be worth tweaking the examples / clarifying them.

@patrickhlauke
Copy link
Member

filed #4382

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants