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

オープン 初心者向け
  • 何か問題がありますか？
#3,433 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
65/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
活発
技術スタック
html
領域
documentation, security

調査の方向性

issueでは要件6.5.5が示され、TOTPに関する追加要件が3つ求められていますが、ソースファイルは指定されていません。まず6.5.5のASVSテキストを見つけ、近接する要件がどのように保存され、書式設定されているかを確認してください。有効期間の文言を更新し、要求された要件を追加してください。その後、公開されたソースに90秒の上限、3つの時間窓、重複、およびトークンの再利用防止が示されていることを確認してください。

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
HTML
スター
3.8k
フォーク
855
平均マージ
1日 9時間
マージ済み PR（30日）
8

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OWASP/ASVS のほかの issue

OWASP/ASVS の issue をすべて見る

似ている issue

Documentation の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。