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

Aperta Adatta ai principianti
  • Qualcosa non va?
#3,433 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
65/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
html
Ambito
documentation, security

Direzione di ricerca

L’issue identifica il requisito 6.5.5 e richiede tre requisiti TOTP aggiuntivi, ma non indica il file sorgente. Inizia individuando il testo ASVS per il requisito 6.5.5 e controlla come sono archiviati e formattati i requisiti vicini. Aggiorna la formulazione sulla durata di validità e aggiungi i requisiti richiesti. Poi verifica che la fonte pubblicata mostri il limite di 90 secondi, tre finestre temporali, la sovrapposizione e la prevenzione del riutilizzo dei token.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
HTML
Stelle
3.8k
Fork
855
Merge medio
1g 9h
PR unite (30g)
8

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OWASP/ASVS

Tutte le issue di OWASP/ASVS

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.