間違ったTOTPトークンを処理するためのベストプラクティス
ユーザー提供のパスワードと6桁のTOTPトークンを持つ2FAシステムを想定しています。最初にパスワードで認証しないとTOTPトークンをテストすることはできないため、トークンを送信する人はだれでもパスワードを知っていると見なされます。各トークンは30秒間生成され、「then current」トークンと一緒に、直前の30秒と30秒の次のウィンドウ内でも有効です。
トークンの入力に時間がかかりすぎてトークンが長くなることはないため、誤ったアラームが表示されることはよくあります。
パスワードが漏洩した可能性があるという想定に基づいて、特定の数の誤ったトークン入力がパスワードの無効化を強制する結果になりますか？（漏洩していない可能性があります。最終的になくなる2番目の要素。）現在広く使用されている2FAシステムがこれを行う場合、一般的なしきい値は何ですか？
私は、RFC 4226が5のスロットルパラメーターを提案していることを知っています。しきい値に達した後、正確に何が起こるかわかりません。アカウントのロックアウト？パスワードは無効ですか？少し待って、再試行を許可しますか？
RFC 4226は他の人が何をしているかを教えてくれませんが、セクション7.3でいくつかの実行可能な提案があります。
明らかに、アカウントとデバイスごとに5回の試行が終了した後、完全なアカウントロックアウトまたは指数関数的に増加する遅延のいずれかが、半永久的に発生するはずです。
カウンタは、同じ認証デバイスに関連付けられている限り、ログインセッション全体および個々のTOTPトークン全体に適用する必要があります。このように、管理者がデバイスファクターロックアウトをリセットする絶え間ない必要性が攻撃下のアカウントに適切な注意を向ける前に、失敗したデバイスファクター認証の試行回数が多すぎて蓄積することは不可能です。そしてパスワードが最終的に変更されると、攻撃によって引き起こされたロックアウトは停止します。
レッスン：
デバイスファクタの保護はパスワードの保護と同じであり、認証フローに関係なく、2つはブルートフォース攻撃からの独立した保護を必要とします。
デバイス要素自体が適切に保護されている場合、パスワードが漏洩したのか、正当なユーザーがデバイスに少しだけ問題を抱えているのかを推測するのは冗長です。
- デバイス要素を保護するには、キー（漏洩に対して）とトークン（盗聴または推測に対して）を保護するだけでは不十分です。
30秒以内に実行できる試行の量を制限します。
したがって、30秒間有効で6桁のトークン（たとえば）があり、30秒間に実行できる試行回数を5に制限すると（ここでも例として）、成功する可能性があります。強引な第2要素の強制は0.0005000005000005％です。