攻撃者は、TOTPデバイスからの過去のコードとそのタイムスタンプに基づいて将来のコードを推定できますか？
最近、TOTPフォブを使用してクラウドホスティングアカウントの一部を保護し始めました。このシステムを使用している間は注意が必要な攻撃ベクトルに慣れている可能性があります（以前の経験はU2F/YubiKeysであり、 TOTP、そして私はTOTPがU2Fとはかなり異なる動作原理を持っていることを知っています）。
フォブをクラウドプロバイダーに登録すると、フォブのハードウェアシリアル番号と、2つの連続するコードの入力を求められました。
私の質問はこれです：期限切れの、しかしタイムスタンプ付きのコードの数（必ずしも2つではない）が与えられた場合、攻撃者は将来のコードを推測できますか？
攻撃者がフォブのハードウェアシリアル番号も持っていた場合はどうなりますか？
または、これらの攻撃ベクトルは両方とも非現実的ですか（つまり、フォブは推測が困難ですが、コードの検証は簡単ですか）？
トークンの実装によって異なります。実装には3つのタイプがあり、最初の1つだけが「脆弱」です。
1：一部のトークンは、シードがハードウェアシリアルから決定論的な方法で計算できる場合に配信されます。これは、「APIを必要とせずに独自のサーバーで使用できる」トークン、または「ユニバーサルTOTPトークン」や「ユニバーサルHOTPトークン」などのそれに類似したトークンを注文した場合に発生する可能性があります。トークンを受け取った後、シリアルのステッカーをはがすはずです。通常、シリアルは推測しにくいものになります。
この場合、シリアルの知識がある人が将来のコードを計算できるようになります。
2：問題のクラウドサービスにトークンを注文しました。トークンが製造されると、シリアル番号とシークレットシードを含むファイルが作成され、クラウドプロバイダーに送信されるため、問題はありません。 （一部のトークンモデルでは、クラウドプロバイダーが独自のシードを使用してトークンを「再初期化」することもできます）次に、クラウドプロバイダーはこのファイルからデータベースを作成します。
クラウドプロバイダーのサイトでシリアルを入力すると、クラウドプロバイダーはその特定のトークンのシードを検索し、そのシードをアカウント内に保存するだけです。
3：APIを備えたトークンシステムが使用されます。このシステムでは、サードパーティの依存サービスが使用する認証APIも提供する「トークンプロバイダー」にトークンを注文します。
Symantec VIPなどの他のトークンシステムは、代わりにAPIに依存しており、ハードウェアシリアルのみをクラウドプロバイダーに登録し、シリアルのみがアカウント内に保存されます。認証が行われると、クラウドプロバイダーはSymantec Serverにリクエストを送信し、コード「xxxxxx」がトークンシリアル「xxxxxxxxxxxx」の正しいコードであるかどうかを尋ねます。これが、同じトークンが複数のサービスに登録されている場合でも、侵害が発生しない理由です。
また、トークンを登録するときに2つの後続コードを提供するように求められる理由は次のとおりです。
後続の2つのコードを指定するように求められる理由は、トークンが使用可能であることを確認して、誤ってアカウントからロックアウトされないようにするためです。このプロセスは再同期プロセスとしても機能し、サービスはこれら2つのコードが存在する特定のウィンドウを検索することで、トークンの「初期同期」を検出します。検索は、数千のコードのように実行され、大幅に非同期化されたトークンは、サービスに登録できます。コードが1つしか指定されていない場合、6桁または8桁が繰り返される可能性が非常に高いため、特定のコードが別の場所に存在する可能性があり、サーバーが誤って誤った初期同期値をトークンに設定し、ロックアウトされたままになる可能性があります。
管理者/ヘルプデスクが開始する再同期プロセスを実行する場合、または多数の無効なコードによって開始される自動プロセスを実行する場合は、後続の2つのコードを提供するように求められます。今回は、無効な再同期を防ぐことはほとんどありませんが、サーバーは通常、約50〜100コードを前方に検索し、50〜100コードを後方に検索する（構成可能）ため、セキュリティを強化します。攻撃者は、1つしか使用されていない場合、コードを推測できますが、もちろん、トークンコードの再利用が可能になるため、サーバーが最後に使用されたコードをさかのぼることはありません。
ただし、結論として、トークンシリアルはアカウント回復のための部分的な認証データになることがあるため、トークンシリアルを共有しないでください。トークンシリアルを使用すると、攻撃者はヘルプデスク担当者を説得して無効にすることができる可能性があります「トークンが黒くなった、何かがおかしい」などのアカウントの2FAで、ヘルプデスク担当者が助けようとしているだけで、ソーシャルエンジニアリングのトリックに陥っています。