パスキーは従来の「パスワード+二要素認証」と比べて、セキュリティ面でどう違いますか?より良いのか、それとも悪いのか?
リモートでのアカウント乗っ取りという脅威に対しては、パスキーは一般的に「パスワード+SMS二要素認証」よりも安全だと考えられている。盗まれるパスワードが存在せず、SIMスワップ攻撃に弱いSMSコードにも依存していないからだ。リモート攻撃を防ぐという観点では、パスキーは確かな前進である。
しかし「アカウントセキュリティ」と「資金の復旧能力」は別の問題だ。従来のパスワードは少なくとも他の検証方法と組み合わせた「パスワードを忘れた」フローでリセットできるし、シードフレーズは特定のデバイスから独立して復旧できるよう設計されている。デバイスの紛失やクラウドアカウントの問題が起きた際の復旧経路という点では、パスキーは実は三者の中で最も未成熟で、単一のサービスプロバイダーに最も依存しているものなのだ。
すでにパスキーでウォレットを保護している場合、今すぐすべき最初のことは何ですか?
まず、あなたのパスキーがデバイス固定型かクラウド同期型かを確認しよう。クラウド同期型(例えばiCloudキーチェーンやGoogleパスワードマネージャーでデバイス間同期されている場合)であれば、そのクラウドアカウント自体に独立した二要素認証が有効になっているか、そしてそのサービスのアカウント復旧プロセスがソーシャルエンジニアリングに対して十分厳格かを確認する。デバイス固定型であれば、ウォレットが第二のバックアップパスキーやバックアップ署名者の登録をサポートしているか確認し、単一デバイスの紛失がアクセス権の永久喪失に直結しないようにする。
どちらの場合でも、最も実践的な次のステップは、ウォレットの設定内に「バックアップ署名方法の追加」や「復旧オプション」がないか確認することだ。もしあれば、実際にデバイスを紛失してから対処するのではなく、今すぐ設定しておこう。
シードフレーズにまったく関わりたくない、面倒だと感じる初心者向けの折衷案はありますか?
ある。できるだけシンプルにしたいという優先順位であれば、妥当な折衷案は次の通りだ。日常使用にはパスキーを使い、支出上限のあるウォレット構造(例えば一日の送金額が一定を超えると追加検証が必要になる)と組み合わせる。そして資産の大部分は、シードフレーズやハードウェアウォレットで保護された、あまり使わない別の「金庫」アカウントに置いておく。パスキー保護のウォレットには日常使いに必要な少額のみを置く。
こうすれば、たとえパスキーの層で問題が起きても、露出するリスクは日常使用分に限られ、資産全体には及ばない——これは実質的に、シードフレーズを日々管理する手間を省きながら、リスク分散も同時に実現する方法だ。
ウォレットベンダーがパスキー機能を宣伝する際によくある誤解を招く表現にはどのようなものがあり、どう見分ければよいですか?
最も一般的なのは、パスキーを「シードフレーズの代替」や「もう秘密鍵管理を心配する必要はない」といった、オールオアナッシング的な売り文句で包装することだ。このようなマーケティング用語を見たら、ベンダーに直接、あるいは公式ドキュメントで確認すべき具体的な質問がある。「もしこのパスキーに紐づくデバイスとクラウドアカウントが同時に使えなくなったら、資産をどう取り戻せますか?」
ベンダーの回答が曖昧だったり、結局のところ「サポートに連絡してください」に行き着くものであれば、それは復旧メカニズムが宣伝されているほど完全ではないことを示すサインだ。それは便利なログイン方法として扱うべきであり、完全な資産保護ソリューションとして扱ってはならない。
ますます多くの暗号資産ウォレットが「Face IDや指紋でログインでき、長いパスワードを覚える必要はない」とアピールするようになっている。この背後にある技術はパスキーと呼ばれる。これは確かに一般ユーザーを長年悩ませてきた問題を解決するものだが、だからといって「パスキーがあればシードフレーズを心配する必要はない」と考えてしまうと、実際にウォレットの復旧が必要になった日に、その思い込みが高くつくことになりかねない。
パスキーはFIDO2/WebAuthn標準の上に構築されている。その仕組みは、あなたのデバイス上で公開鍵と秘密鍵のペアを生成するというものだ。秘密鍵はデバイスの安全なハードウェア要素——スマートフォンのSecure Enclave、コンピューターのTPMチップ、あるいは専用のハードウェアセキュリティキーなど——内に永続的に保存される。原則として、この秘密鍵はその安全な要素から「決して外に出ない」。そして各パスキーは特定のウェブサイトのドメインにのみ紐づけられるため、偽装されたウェブサイトがあなたのパスキーを騙して別の場所にログインさせることはほぼ不可能になっている。
パスキーが急速に普及している理由は、ほとんどの一般ユーザーが実際に遭遇する攻撃手法——フィッシングサイト、複数サービスでの同一パスワードの使い回し、過去の情報漏洩データを使ったクレデンシャルスタッフィング——に正面から対抗できるからだ。共有される秘密情報がネットワーク上を一切流れず、盗まれるパスワードも存在しないため、こうした拡張性の高い自動化された従来型攻撃は、パスキーに対してはほぼ無効化される。たとえ攻撃者がロック解除された状態のデバイスを手に入れたとしても、ほとんどの実装では何かに署名する前に生体認証が必要となる——これはアカウントレベルのセキュリティにおける確かな前進だ。
問題は、よくあるが危険な使用パターンにある。パスキーを攻撃者とあなたの資金の間にある唯一の壁として扱ってしまうことだ。多くのユーザーは、パスキーがすでにシードフレーズに取って代わる完全なセキュリティソリューションだと誤解している。これは根本的に間違っている。なぜならパスキーとシードフレーズの最大の違いは、シードフレーズには標準化された持ち運び可能なバックアップ機構(紙に書いた単語列で、どのデバイスでもウォレットを復元できる)があるのに対し、パスキーにはそれに相当する仕組みが一切ないという点にあるからだ。
これがパスキーの最も見落とされやすい弱点だ。もしあなたのパスキー復旧方法が、結局のところ「自分のiCloudアカウントに頼る」ことに行き着くのであれば、あなたの資金を実際に保護しているのはパスキーではなくiCloudだということになる。クラウド同期型のパスキーは、あなたの資金の安全性を、完全には信頼できず独立した監査もできないサードパーティサービス全体に間接的に依存させてしまう——このサービスはアカウントを停止するかもしれず、データ漏洩に遭うかもしれず、あるいは攻撃者がサポートエンジニアリング(サポート担当者を説得してアカウントをリセットさせる)によって回避されるかもしれない。逆に、クラウド同期を一切行わない完全デバイス固定型のパスキーを選べば、クラウドリスクは排除できるが、別のリスクを背負うことになる。デバイスを紛失または破損し、別途独立したバックアップ署名者を登録していなければ、アクセス権を永久に失うことになるのだ。
業界で認識されているより安全なアプローチは、パスキーを唯一の防衛線としてではなく、マルチファクター構造の中の一要素として扱うことだ。例えば、複数の承認を必要とするマルチシグウォレットと組み合わせる、支出上限のあるスマートコントラクトの中にパスキーを組み込む、あるいは単一のクラウドサービスに依存しない独立した復旧経路を別途維持する、といった方法だ。これは実際、健全なシードフレーズ管理の核心的な原則と同じものである——パスワードであれ、デバイスであれ、クラウドアカウントであれ、単一の要素があなたと全資金の間にある唯一の壁になることを決して許してはならない。
パスキーで暗号資産ウォレットを保護し始める前に、自分自身に具体的な質問をしてみてほしい。もし今日、ログインに使っているこのスマートフォンを失くしたら、資産を取り戻す別の経路はあるだろうか?もし答えが「クラウドアカウントに再ログインするしかない」であれば、あなたが実際に負っているリスクは、そのクラウドアカウント自体のセキュリティと直接結びついている。ウォレットが独立したバックアップ署名者や復旧メカニズムをサポートしているかどうかを数分かけて確認することは、事後になって締め出されていることに気づくよりも、ほぼ常にはるかに安上がりである。