V6.5.5: Does not take into account clock "drift"

Abierto Apto para principiantes
  • ¿Algo no está bien?
#3,433 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
65/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
html
Área
documentation, security

Línea de trabajo

El issue identifica el requisito 6.5.5 y solicita tres requisitos TOTP adicionales, pero no indica el archivo fuente. Empieza por localizar el texto de ASVS para 6.5.5 y comprueba cómo se almacenan y se formatean los requisitos cercanos. Actualiza la redacción sobre el período de validez y añade los requisitos solicitados. Luego verifica que la fuente publicada muestre el límite de 90 segundos, tres ventanas de tiempo, la superposición y la prevención de la reutilización de tokens.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

V6 (prev V2)

The following text does not take into account potential network delay, human latency and a client device whose clock is running slightly faster:

6.5.5 Verify that out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out of band requests must have a maximum lifetime of 10 minutes and for TOTP a maximum lifetime of 30 seconds. 2

The RFC-6238 section 6 states:

6. Resynchronization

Because of possible clock drifts between a client and a validation
server, we RECOMMEND that the validator be set with a specific limit
to the number of time steps a prover can be "out of synch" before
being rejected.

This limit can be set both forward and backward from the calculated
time step on receipt of the OTP value. If the time step is
30 seconds as recommended, and the validator is set to only accept
two time steps backward, then the maximum elapsed time drift would be
around 89 seconds, i.e., 29 seconds in the calculated time step and
60 seconds for two backward time steps.

This would mean the validator could perform a validation against the
current time and then two further validations for each backward step
(for a total of 3 validations). Upon successful validation, the
validation server can record the detected clock drift for the token
in terms of the number of time steps. When a new OTP is received
after this step, the validator can validate the OTP with the current
timestamp adjusted with the recorded number of time-step clock drifts
for the token.

Also, it is important to note that the longer a prover has not sent
an OTP to a validation system, the longer (potentially) the
accumulated clock drift between the prover and the verifier. In such
cases, the automatic resynchronization described above may not work
if the drift exceeds the allowed threshold. Additional
authentication measures should be used to safely authenticate the
prover and explicitly resynchronize the clock drift between the
prover and the validator.

To account for this, allow a single TOTP code to remain valid for a maximum of 90 seconds (3 total steps).

So change the maximum lifetime and add another 3 requirements:

6.5.5 Verify that out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out-of-band requests must have a maximum lifetime of 10 minutes, and TOTPs a maximum lifetime of 90 seconds. 2
6.5.* Verify TOTP codes to stay valid across three 30-second time windows and stay valid with a 30-60 seconds overlap between the previous and the next TOTP code 2
6.5.* Verify that the application prevents TOTP token reuse by ensuring a code from an accepted time window is invalidated immediately upon successful verification. 2
Lenguaje dominante
HTML
Estrellas
3.8k
Forks
855
Merge medio
1 d 9 h
PR fusionados (30 d)
8

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OWASP/ASVS

Todos los issues de OWASP/ASVS

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.