パスキーは、二重の鍵がかかった郵便受けだとイメージしてほしい。誰でも公開されている投函口に手紙を入れることはできるが、開けて中身を確認できるのは、個人の鍵を持つ人だけだ。これはまさに、あるテクノロジーメディアが最近公開した解説記事でパスキーの仕組みを説明する際に使った例え——公開鍵はウェブサイト側に置かれ、秘密鍵はあなたのデバイスに保管される。両方が揃って初めて機能する。
従来のパスワードが抱える問題は、多くの人がすでに知っている通りだ。サイト側はパスワードを平文で保存すべきではないため、ハッシュ処理を行い、さらにランダムな「ソルト」を加えることで、同じパスワードでも異なるハッシュ値になるようにし、データベース流出時に元のパスワードが復元されるリスクを下げている。だが、この仕組みの弱点はアルゴリズムではなく、人間側にある——多くの人は覚えやすさを優先し、複数のサービスで同じ弱いパスワードを使い回してしまう。そしてフィッシングサイトはまさにこの点を突き、ユーザーに自ら進んでパスワードを「差し出させる」よう仕向けてくる。
パスキーはどうやってこの弱点を埋めるのか
パスキーでは、何かの文字列を覚える必要が一切ない。ログイン時、サイトはデバイスに対し、公開鍵に対応する秘密鍵を使った認証を求める。この秘密鍵はスマートフォンやパソコンの保護された保存領域に置かれ、Face ID、Windows HelloのPIN、あるいは指紋認証によって呼び出される。つまり、「デバイスを所持していること」と「PINや生体情報を知っていること」という二つの条件を同時に満たす必要があり、これは従来なら二段階認証でようやく到達できたセキュリティレベルを、一度に満たしていることになる。
さらに重要なのは、パスキーを作成する際に特定のドメインと紐付けられる点だ。見た目がそっくりの偽サイトを開いたとしても、デバイスは秘密鍵を渡そうとしない。つまり、「パスワードをフィッシングページに入力してしまう」という行為自体が根本的に意味をなさなくなるわけだ。加えて、パスキーの仕様自体が高い強度を前提としているため、「簡単なパスキーを設定する」といったことはそもそも不可能であり、データベースが流出しても攻撃者が手に入れられるのは公開鍵だけ——そしてそれは元々秘密でも何でもない。
保存場所こそが、本当の悩みの種
パスキーの代償は、デバイスやソフトウェアに紐付いている点にある。紛失したり、別のシステムをまたいで使おうとしたりすると、途端に行き詰まってしまう。iOSとmacOSではデフォルトでApple Passwordsに保存され、AndroidはGoogle Password Managerに依存し、Windows 11では「設定 > アカウント > パスキー」の下に格納される。一方、Linuxには現時点でネイティブのサポートがない。もし使っているデバイスが異なるエコシステムに散らばっている場合、すべてのパスキーを単一システムのアプリ内にとどめておくと、別のスマートフォンに乗り換えてログインする際に面倒なことになる。QRコードを使ったクロスデバイスログインを提供するサービスもあるが、毎回スムーズにいくとは限らない。
共有もまた、もう一つの現実的な制約だ。かつては信頼できる相手にパスワードを教えるのは一言で済むことだった。パスキーで同等の手軽さを実現するには、共有ボールト機能に対応したパスワード管理ツールが必要で、単純なデバイス内蔵の仕組みだけではこれを実現できない。こうした理由から、パスキーを複数プラットフォーム対応の同期機能を持つパスワード管理アプリに一元的に保存する方が、各社バラバラのデフォルトツールに任せるよりも現実的だ。さらに一歩進めるなら、YubiKeyのような物理セキュリティキーにパスキーを保存するという選択肢もある。
現時点では、多くのサービスがパスキーとパスワードを併存させている。パスキーがパスワードを完全に置き換えるケースもあれば、あくまで補強にとどまり、置き換えには至らないケースもある——もしあなたのアカウントが後者に当てはまるなら、そのパスワード自体を十分に強固にしておくことを忘れないでほしい。そうでなければ、仕組み全体が最も弱い部分に足を引っ張られてしまうことになる。
