パスキーはパスワードよりも優れています。
誰もが同意するわけではありません。しかし、一部の反対意見は、パスキーの仕組みを理解していないことに起因していることがわかりました。
懐疑的な方も無理はありません。パスキーの使い方は簡単ですが、技術的なニュアンスを理解するのはなかなか大変です。それでは、詳細を見ていきましょう。
パスキーとは何か
パスキーとは、WebAuthn認証標準の非公式な名称です。WebAuthnは非対称暗号化（公開鍵暗号）を採用しています。パスキーを作成すると、公開鍵と秘密鍵のペアが生成されます。ウェブサイトは公開鍵を取得します。秘密鍵はユーザーの所有物であり、秘密に保たれます。秘密鍵は認証プロセスを円滑に進めるために使用されますが、検証プロセスを完了するために直接共有されることはありません。また、公開鍵から推測することもできません。
秘密鍵は保存場所に関連付けられており、保存には主に 2 つのオプションがあります。
クラウドストレージ
Apple、Microsoft、Google はすべて、アカウントのパスワードとパスキーの両方を保存できます。
PCワールド
パスキーの半分をクラウドベースのサービスに保存すると、どのデバイスからでもアクセスできるため、柔軟性が最大限に高まります。
多くの人にとって、この方法はMicrosoft（Windows）、Apple、またはGoogleアカウントを介して行われます。また、ほとんどのサードパーティ製パスワードマネージャーに保存することもできます。
現在、クラウドサービス間でパスキーを自由に転送することはできませんが、今後数ヶ月で状況は改善されるはずです。AppleはiOS 26とmacOS 26でポート（CXP）機能を有効にしました。サードパーティ製のパスワードマネージャーBitwardenも同様にポート機能を有効にし、パスキーとパスワードの両方を他の互換性のあるサービス間で安全にインポートおよびエクスポートできるようになりました。
クラウドストレージの主なメリットは利便性です。繰り返しになりますが、アカウントにアクセスできる限り、保存したパスキーを使用できます。しかし、デメリットは、誰かがアカウントに侵入した場合、そのパスキーも使用できてしまうことです。
ローカルストレージ
ユビキー
パスキーが初めてリリースされた当時は、スマートフォンやPCにローカルに保存されていました。YubiKeyやGoogle Titan Security Keyなどのセキュリティキーに保存することもできました。
最近では、スマートフォンやPCに保存されたパスキーのほとんどは、サインインしているクラウドアカウントにリンクされます。完全に制御できるハードウェアにパスキーを保存したい場合は、PC専用のローカルパスワードマネージャー（KeePassXCなど）か、セキュリティキーを使用する必要があります。
ローカルストレージの利点は、悪意のある人物がパスキーを取得するにはハードウェアにアクセスする必要があることです。一方、欠点は、デバイスを紛失し、他のパスキーやログイン方法がない場合、アカウントにアクセスできなくなることです。
ローミング認証子とプラットフォーム認証子
上記ではパスキーの保存方法を具体的に定義しましたが、WebAuthn標準では定義が異なることに注意してください。WebAuthnでは「ローミング」認証子と「プラットフォーム」認証子が区別されています。セキュリティキー（例：YubiKey）はローミング認証子の一例で、異なるデバイス間で移動できます。PCやスマートフォンなどのデバイスは「プラットフォーム」認証子と見なされ、パスキーをデバイス間で持ち運ぶ必要はありません。
パスキーとは何か
使用に制限はありません
PCワールド
パスキーは、それが作成されたサービスやデバイスに紐付けられるため、エコシステムと結び付けられていると考える人もいます。（つまり、Google、Apple、Microsoft、そしてサードパーティのパスワードマネージャーは、パスキーを自由に移動できないように、ユーザーを自社のサービスに閉じ込めようとしているのです。）
しかし、パスキーはパスワードとは異なります。1つのサイトに対して複数のパスキーを作成できます（パスワードは1つしか設定できません）。家の鍵に例えてみましょう。特定の錠前の鍵は、一度に1つの場所にしか存在できません（必要な時に鍵が見つからないのはそのためです…）。しかし、同じ錠前を開ける鍵は複数あります。家の鍵とパスキーの違いは、予備の家の鍵はコピーであるということです。予備のパスキーは固有のものであり、他の場所で使用するためにコピーすることはできません。そのため、依然として安全です。
つまり、Microsoft アカウント用に特定のサイトのパスキーを作成し、Apple アカウント用に別のパスキーを作成し、さらに Google アカウント用に 3 つ目のパスキーを作成すれば、すべてログインに使用できます。これらのエコシステムのいずれかに完全に閉じ込められるわけではありません。
デバイスやサービスに永遠に縛られることはない
りんご
リリース時には、パスキーは作成されたデバイスやサービスに具体的に関連付けられていたため、パスキーを複数作成できることは、パスキーを使用できるようにする上で非常に重要でした。
ある意味、これはセキュリティ機能と言えるでしょう。パスキーを決して移動できないようにしておけば、誰かがその秘密鍵を盗み出す心配もなくなるのです（少なくとも、このXKCD方式を除けば）。
しかし、これはローカルに保存されたパスキーにのみ適用されます。クラウドにパスキーを保存していた場合でも、パスキーが保存されているアカウントに誰かが不正アクセスできないように注意する必要がありました。
しかし、それは多くの人にとって面倒なことでもありました。パスキーが保存されているデバイスが紛失、盗難、または破損した場合、バックアップのパスキーや代わりのログイン方法を設定していなければ、どうしようもできないのです。
そこで現在、パスキーを安全に転送する機能が導入されています。
パスキーの脆弱性
さて、脆弱性についてお話ししましょう。パスキーとパスワードの比較について、よく聞かれる混乱を整理してみましょう。これらのシナリオはすべて、実装が正しく行われていることを前提としています。
フィッシング
フィッシングとは、人々を騙して機密情報を共有させようとする行為と定義できます。これは広範な概念であり、ソーシャルエンジニアリングやマルウェアなど、様々な種類があります。
単純なフィッシング攻撃は、正規の企業を装った悪意のある人物が、メール、テキストメッセージ、または電話で認証情報を要求します。より巧妙な手口では、正規の企業を装った偽のウェブサイトに被害者を誘い込みます。ログイン情報を入力すると、ユーザーIDとパスワードが盗まれます。二要素認証を設定しているアカウントであっても、必ずしも安全とは限りません。その情報はリアルタイムで盗まれる可能性があります。
トロイ・ハント / HaveIBeenPwned
専門家によると、パスキーがフィッシング攻撃に耐性を持つ主な理由は2つあります。1つ目は、攻撃者がパスキーを構成する要素を実際に盗むことができないことです。公開鍵は設計上公開されており、秘密鍵はユーザーのみが管理します。この2つの鍵は連携して認証プロセスを完了する共有データを作成しますが、実際に交換されるのは秘密鍵ではありません。そのため、ユーザーIDとパスワードのように盗まれたり、悪用されたりすることはありません。
第二に、この規格では、パスキーは元のドメインでのみ使用できます。偽のウェブサイトが認証にパスキーを使うように仕向けてきた場合、ブラウザはパスキーにリンクされた元のドメインを確認し、その試みを阻止します。フィッシングドメインは一致しません。パスワードの自動入力のように、このプロセスを上書きすることもできません。認証プロセスは開始されず、強制的に開始することもできません。
同様に、攻撃者が正規のログインフォームをiframe内に配置した場合、それは機能しないはずです。iframeが使用されている状態で認証が機能するには、ドメイン間の連携を確立し、不一致を許容できるようにする必要があります。偽のフィッシングサイトは、偽のドメインと正規のドメイン間でこの実装を確立することは不可能ではありませんが、おそらく不可能でしょう。
注：この情報は現時点でのものです。攻撃者は常にこのような障害を回避するための新しい方法を考案しています。状況は時間の経過とともに変化する可能性があります。
中間者攻撃（MitM）
中間者攻撃では、ハッカーは文字通り、あなたと通信先のサイトの間に割り込み、データが通過できるようにします。この攻撃のバリエーションの一つとして、攻撃者はあなたの認証情報（2要素認証コードを含む）を盗み、正規のサイトに送り込みます。その後、攻撃者は有効なセッションをアクティブにすることができ、アカウント乗っ取りを開始するために2要素認証は不要になります。
パスキーはこの種の認証情報の盗難から保護しますが、セッションハイジャックと呼ばれる亜種には効果がありません。より伝統的なセッションハイジャックは、Cookieの盗難に重点を置いており、攻撃者はCookieを自分のデバイスに配置し、検証済みのセッションを通じてアカウントにアクセスすることができます。
ジャスティン・モーガン / Unsplash
パスキーではこのような攻撃から身を守ることはできません。だからこそ、システム上のマルウェア対策が極めて重要です。ウェブサイト運営者は、セッションをデバイスやロケールに紐付けるなどして、この種の攻撃を軽減できます。しかし、これはパスキーの管轄外です。認証が行われれば、パスキーの役割は終わります。
理論上、システム上のマルウェアは、ブラウザがWebAuthn標準を設計通りに実行する機能を妨害したり改ざんしたりする可能性もあります。そのため、インストールするアプリケーションには注意が必要です。ただし、これはパスキーを非難するものではありません。マルウェアはパスワードマネージャーから直接パスワードを盗むことも同様に容易です。
最後にパスキーの検討事項
全体的に、パスキーはパスワードよりも安全で、パスワードと 2 要素認証を使用するよりも便利です。
しかし、生体認証データが保護されていないと考える理由がある場合、パスキーをどのように保護するかが重要になる場合があります。オンラインセキュリティの観点からは、指紋や顔認証の方がPINよりも安全です。PINはより簡単かつ広範囲に共有できます。しかし、一部の法域（米国など）では、PINを政府に開示することを強制することはできません。生体認証はPINと同じようには保護されていません。
ほとんどの人にとって、このような区別は問題にならないでしょう。しかし、そのような問題を検討しなければならない人にとっては、知っておく価値があります。
