https://u-rei.com/tags/webauthn/Recent content in WebAuthn on U-REI.comHugoja-JP2023-2026 Kosuke UchidaThu, 13 Aug 2026 04:00:00 +0900https://u-rei.com/posts/2026/08/2026-08-12-vaultwarden-webauthn-titan-key-login-failure/Thu, 13 Aug 2026 04:00:00 +0900https://u-rei.com/posts/2026/08/2026-08-12-vaultwarden-webauthn-titan-key-login-failure/<p>セルフホストの<a href="https://github.com/dani-garcia/vaultwarden">Vaultwarden</a>にGoogle Titanセキュリティキーを2段階認証(FIDO2 WebAuthn)として登録したら、登録自体は一発で成功するのに、その後のログインが必ず失敗する、という不可解な症状にはまった。同じ物理キーはGoogleやwebauthn.ioでは何の問題もなく使える。原因を突き止めるのに数週間かかったので、記録として残しておく。</p> <h1 id="症状">症状</h1> <ul> <li>Titanキーを2FAとして登録すると成功する(タッチ要求 → 登録完了、というふつうの流れ)</li> <li>ログイン時、ブラウザの「セキュリティキーを挿入してタッチしてください」ダイアログが出たまま反応がなく、最終的に<code>NotAllowedError: The operation either timed out or was not allowed</code>でタイムアウトする</li> <li>同じ現象がLinux(Chrome)、Mac mini(Chrome/Firefox)、スマートフォンでも再現。OSやマシンには依存しない</li> <li>同じキーをGoogleアカウントやwebauthn.ioに登録すると問題なく動く。キー自体は壊れていない</li> </ul> <h1 id="除外していった仮説">除外していった仮説</h1> <p>原因を絞り込むまでに、以下をひとつずつ潰していった。</p> <ul> <li><strong>RP ID/ドメインの不一致</strong> — ブラウザのネイティブダイアログには正しいドメインが表示されている</li> <li><strong>ブラウザ拡張機能・広告ブロッカーの干渉</strong> — 無効化しても変化なし</li> <li><strong><code>webauthn-connector.html</code>の<code>Permissions-Policy</code>ヘッダーに<code>publickey-credentials-get</code>が含まれていない</strong> — Caddy側でヘッダーを上書きするテストを本番で実施したが変化なし</li> <li><strong>サーバー側での認証情報の保存/シリアライズ不具合</strong> — DBに保存された<code>cred_id</code>はログイン時にそのままバイト単位で一致しており、サーバー側で壊れている様子はない</li> <li><strong>U2F互換用の<code>appid</code>拡張を無条件に送っていることが原因では?</strong> — 移行済み(<code>migrated: true</code>)のクレデンシャルにだけ<code>appid</code>を送るようパッチしたVaultwardenをビルドして本番にデプロイし、Chromeの内部FIDO/CTAPログ(<code>--vmodule=&quot;*fido*=3,*webauthn*=3&quot;</code>)で比較したが、タイムアウトまでの挙動パターンは無変化。この仮説は外れ</li> <li><strong>本家Bitwarden(C#実装)との差異</strong> — <code>WebAuthnTokenProvider.cs</code>を確認したが、Vaultwardenとほぼ同じ流れ(<code>UserVerificationRequirement.Discouraged</code> + 無条件の<code>AppID</code>拡張)で組まれており、Vaultwarden固有のバグという線も薄い</li> </ul> <h1 id="突破口-firefoxで登録し直すとpinを聞かれた">突破口: Firefoxで登録し直すとPINを聞かれた</h1> <p>外堀を埋めていく中で、ふと「登録済みのキーを消して、Firefoxで登録し直してみたらどうなるか」を試した。すると、Chromeでは一度も出なかった<strong>セキュリティキーのPIN入力を、Firefoxは要求してきた</strong>。</p> <p>このFirefoxで登録し直したクレデンシャルでログインすると、Chrome・Firefoxどちらからでも成功する。念のため2回繰り返して確認した。</p> <ul> <li>Chromeで再登録 → 失敗(何度やっても同じ)</li> <li>Firefoxで再登録 → 成功(Chrome/Firefoxどちらのログインも通る)</li> </ul> <p>「登録時にPINによるユーザー検証(UV)が実際に行われたかどうか」が明暗を分けているのは間違いなさそうだった。</p> <h1 id="dbレコードを直接比較する">DBレコードを直接比較する</h1> <p>同じ物理キーを、登録に使うブラウザだけ変えて2回登録し、Vaultwardenの<code>twofactor</code>テーブル(SQLite)に保存されるレコードを直接比較した。</p> <table> <thead> <tr> <th></th> <th>Chromeで登録(PINなし)</th> <th>Firefoxで登録(PINあり)</th> </tr> </thead> <tbody> <tr> <td><code>user_verified</code></td> <td><code>false</code></td> <td><code>true</code></td> </tr> <tr> <td><code>counter</code>(ログイン後)</td> <td><code>0</code>(一度も成功していない)</td> <td>ログインのたびに増分</td> </tr> <tr> <td>クレデンシャルIDの長さ</td> <td>160 bytes</td> <td>288 bytes</td> </tr> </tbody> </table> <p><code>registration_policy</code>はどちらも<code>discouraged</code>のまま変わらないが、実際にUVが行われたかどうかでクレデンシャルIDの長さそのものが変わっている。Titanキーは、UVなしで作られた短い方のクレデンシャルではログインの<code>GetAssertion</code>を完走できない、という個体差(あるいは仕様)を持っているらしい。</p>