Japanese Translation:

最近の「パスキーはセキュリティ上のリスクである」という主張を強く否定し、むしろユーザーアカウントを守るための現在最も効果的な方法として残っていることを明言しています。これらのデジタル鍵は WebAuthn という技術標準を活用しており、ウェブサイトにオペレーティングシステムのバージョンやファームウェアといった機密デバイスの詳細を暴露することなくログインを保護します。Hacker News などのプラットフォームで流行している「従来のパスワードか TOTP コードに戻れ」というアドバイスは、認証（attestation）の仕組みに対する誤解に基づいています。実際には、YubiKeys を含むハードウェアツールですら企業による検証に必要な標準的な証明書を利用しており、「隠された制限への恐怖」は事実無根であることが disproved（立証）されます。

現在パスキーを回避することは、ユーザーをフィッシング攻撃や認証情報のリレー攻撃に対して不必要に脆弱にし、実質的なセキュリティ上の利点をほとんどもたらしません。したがって、ウェブサイトが提供している場合、個々は常にパスキーを積極的に採用し、鍵を信頼できるパスワードマネージャーに保存すべきです。企業は、標準的な認証（attestation）と制限的なブロック機能を不当に同一視する誤情報を無視することで、堅牢な業界基準を維持することができます。直ちに取り得る教訓は明確です：技術的な不正確さに基づいてこの優れた技術を放棄することを行わないでください。

「パスキーは罠だ」なる投稿の実態：なぜ使い続けなければならないのか

インターネット上およびハッカーニュースで頻出する**「パスキーは罠であり、使用すべきではない」という主張について**の検証記事を整理しました。技術非専門家の市民向けに、主要な誤解と事実を解説します。

投稿が展開している主張と論理

投稿者は以下の経緯で、パスキーの使用を強く推奨していないとしています。

隠されたダイヤル（Hidden Dial）
- パスキーは**認証証明（Attestation）**をサポートしており、ウェブサイトは暗号学的証拠を求めることができる。
- これが強化されれば、やがては承認されたソフトウェアのみ、承認された OS のみ、かつ改変されていない環境でのログインしか許可されなくなるだろうと予測している。
制限の連鎖
- LineageOS の使用禁止や、Netflix におけるパスワード共有禁止など、実装による制約が増える。
- uBlock Origin の利用や FIDO アライアンスのメンバーシップリストへの準拠、イギリスの画像スキャン提案などと合わせれば、「ユーザーの利益を最優先に設計されていない」と結論づけている。

注釈：これらの主張は確かに魅力的な物語のように聞こえますが、実際にはそのようには機能していません。

事実：パスキーは認証証明を行わない

大多数の人が利用するパスキー（iCloud キーチェーン、Google パスワードマネージャー、1Password、Bitwarden など）について。

認証証明ステートメントの提供
- 一切の認証証明ステートメントをウェブサイトに対して提供しません。
- ウェブサイト側が照会を試みても、返される情報は「なし」です。
実装の実態
- オープンソースのパスキーライブラリ開発者としての知見に基づく事実です。
- もし明日から消費者向けウェブサイトが認証証明付きのみを受け付けるようになった場合、ほぼすべてのユーザーを即座にブロックしてしまうことになります。
業界の動向
- 消費者向けサイトのガイドラインでは何年も前から、認証証明自体のリクエストは推奨されていません。

事実：認証証明とは思いっきり違います

投稿者は「認証証明＝承認された環境（OS・ファームウェア等）の使用証明」と定義していますが、これは誤りです。

WebAuthn の仕組み
- 認証器の製造元とモデルを示す
```
AAGUID
```
  を伴う証明書チェーンによって裏付けられた情報が通知されます。
- しかし、OS のバージョンやルート化の有無、ブラウザの状態、ファームウェアのバージョン、デバイス本体の色などについては一切言及していません。

事実：YubiKey は「回避」できません

投稿者はハードウェアキーへの移行を推奨していますが、これは逆説的です。

YubiKey の実態
- YubiKey は認証証明を実装している代表的な認証器です。
- すべての製品に Yubico から発行された認証証明書が同梱されています。
企業機能の存在
- 組織向けの認証証明機能は、承認されたハードウェアキーの使用を強制するために設計されています。
結論
- 「認証証明が心配」という理由で YubiKey を避けるなら、それは投稿者の意図とは真逆の方向へと導きます！

事実：TOTP はフィッシングに対して脆弱です

投稿者が TOTP（一時パスワード）を「優れた解決策」として挙げていますが、重大な弱点があります。

フィッシング攻撃へのリスク
- ユーザーが TOTP コードを入力するウェブサイトに間違える可能性があります（例：
```
examp1e.com
```
  に
```
example.com
```
  のコードを入力）。
- Evilginxなどのフィッシングキットが中間に立ち、リアルタイムでパスワードとコードを真のサイトに転送し、セッションごとにお金を落としてしまうケースが存在します。
パスキーの優位性
- これは理論上の話ではなく、現在多くのアカウント乗っ取り事件で実際に起きている事実です。
- パスキーは作成されたドメインにバインドされており、ブラウザが別の類似ドメインでもコードを発行しません。
- 読み上げるコードもなく、ユーザーが間違える余地もありません。
投稿者の矛盾
- 著者自身も補足で「パスキーは中間者攻撃に対する抵抗力を持つ」と認めつつ、それでも使用を避けるよう勧めています。
- これとは言うものの、フィッシング耐性のある認証手段を、フィッシング可能なものへと置き換えるのは極めて悪質な取引です。

結論：何をするべきか？

✅ やるべきこと

パスキーを使い続けましょう！
- ウェブサイトが提供している場合は、必ず受け取り、信頼できるパスワード/パスキーマネージャーに保存してください。
- 資格情報を移動させたい場合は、その機能をサポートしているプロバイダーを選んでください。
現状のリスク評価
- 今日パスキーを避けながら認証証明機能の普及を待つことでは何も保護されることはなく、ただフィッシング攻撃にさらされやすくすることだけです。

⚠️ 懸念点と今後の展望

認証証明が消費者向けのログインに浸透してくることへの懸念がある場合、それは強く異議申し立てする価値があります（ただし現状はまだ発生しておらず、最大のサービス提供者もこの機能をサポートしていません）。

著者の経歴と信頼性

この分野で実績を持つ著者は以下の活動を行っており、現在可能な限りあらゆる場所でパスキーを使用しています。

WhyNoPasskeys.comの作成（導入状況の追跡のため）
SaaS 企業でのパスキーサポートの開発・展開
オープンソースのパスキーライブラリの作成とセキュリティレビューの実施
「ウェブサイトでのパスキー使用におけるセキュリティ上の考慮事項」などの論文執筆
パスキー実装に対し、広範なセキュリティテストの実施
認証証明機能の非実装という限界についても開示的に認めています

最重要メッセージ 「パスキーは罠ではありません。アカウント保護のために現在最も優れた手段です。」

この記事が有益でしたら、作者へのコーヒー購入や購読、メンバーシップ登録をご検討ください。

パスコードは罠ではありません