You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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
The text was updated successfully, but these errors were encountered:
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.
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:
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
The text was updated successfully, but these errors were encountered: