Tender Surrender

最近、パスキーが使いづらい、という声を目にします。作ったはずのパスキーが見つからないために、使いたいサービスにログインできず困った、という人の投稿も何度か観測しました。

そこでこのブログ記事では、どうしてそういうことが起こってしまうのか、どうすればそういう状況を回避できるのか、ユーザーが取れる対策にはどういうものがあるのか、サービス側はどうすればそのように感じるユーザーを減らせるのか、について考えていきたいと思います。

2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。

本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。

パスキーはフィッシングに強く、テクノロジーに詳しくないユーザーでも使いやすい新しい認証方式で、いずれパスワードを置き換えると言われています。この記事では、パスキーの基本と、これからのウェブにとってパスキーがどういう意味を持つのかについてまとめてみます。

長い記事なので先に結論を書きます。

Chrome、Firefox および Safari で SharedArrayBuffer や高精細タイマーが使えるようになりました。そのためには cross-origin isolation という状態を有効にするのですが、親となる HTML ドキュメントに下記 2 つのヘッダーを送ります。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

ただ、これを有効にするには様々な条件と制約が存在し、現段階では多くのサイトは苦戦するでしょう。とりあえず従来通り Chrome で動けばいいやということであれば、デプリケーショントライアル (Deprecation Trial) に登録してしばらく様子を見る、という選択肢が無難かもしれません。

長い記事なので先に結論を書きます。

Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。

• すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。
• HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。
• HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニケーションを制御する。
• すべてのリソースには適切な Content-Type ヘッダーと X-Content-Type-Options: nosniff ヘッダーを追加して、cross-origin からの悪意ある読み込みを防ぐ。