HN 日本語サマリー

← 一覧へ戻る
セキュリティ

パスキーは好きではない

I don't like passkeys (hawksley.dev)

664 pointsby ethanhawksley651 コメント

要約

この記事は、パスキーが個人利用には不向きであると主張しています。パスキーはフィッシング耐性やデータ漏洩時の安全性が高い一方で、アカウントの永久ロックアウト、デバイス紛失、ハードウェアキーのコスト、OSへの依存といったリスクを個人にもたらすと指摘しています。著者は、パスワードマネージャーとTOTPアプリの組み合わせが、現時点では個人にとってより良い選択肢であると考えています。

全文翻訳

パスキーは好きではない

ここ数年、テクノロジー業界はパスキーをログインの究極の解決策として押し進めてきました。多くの大手テック企業は、ログインするたびにパスキーがいかに簡単で手間いらずかを「親切に」教えてくれます。それをやめさせる唯一の方法は、折れてパスキーを設定するか、設定に深く潜ってオフスイッチを見つけるかのどちらかです。

[画像: Googleの「可能な限りパスワードをスキップ」設定]

Googleは、この設定を「可能な限りパスワードをスキップ」(別タブで開く)と呼ぶほどです。Microsoftは、Microsoftアカウントでパスワードなしにする(別タブで開く)ことを推奨しています。

パスキーは素晴らしいテクノロジーです。パスキーは作成されたサイトに紐づいているため、ハッカーの偽ログイン画面でフィッシングされることはありません。もしサイトがデータ侵害に見舞われたとしても、パスキーは非対称暗号化されており、サーバー側の詳細から復元されることはありません。

これにより、パスキーは企業環境には最適ですが、個人のセキュリティには不向きです。個人にとっては、最大の危険はむしろアカウントへの永久的なアクセス不能、自動アカウント禁止、デバイスの紛失です。パスキーを使用することで、中間者攻撃に対するセキュリティは向上しますが、アカウントへのアクセスを失う可能性が高いシナリオに直面します。

標準的なログインフローを通じたフィッシングはパスキーによって排除されますが、それは偽の安心感を生み出します。アカウントのセキュリティは、依然として最も弱いリカバリ方法、つまりSMS、メールリンク、セキュリティ質問などによって決まります。これらのリカバリ方法が有効になっていない場合、ユーザーにとっては永久的なロックアウトのリスクが残ります。

ハードウェアキー

設計上、ハードウェアキーにパスキーのバックアップを作成することはできません。パスキーは追加または削除することしかできず、移動させることはできません。代わりに、2〜3個のハードウェアキーを購入し、すべてのサイトで各キーを登録する必要があります。これはすぐに高価になり、アカウント数が増えるとスケーリングが悪くなります。

ハードウェアキーは、ウェブサイトがユーザー名を入力する代わりにユーザー名を照会できる、検出可能な認証情報をサポートしています。これらはウェブサイト開発者の間でますます人気が高まっていますが、ハードウェアキーあたり25〜100アカウント(別タブで開く)という制限があり、最上位のキーでも最大300アカウントまでです。この制限を超えると、いくつかのアカウントを削除するか、別のハードウェアキーセットを購入する必要があります。

同期パスキー

AppleとGoogleはどちらも、あなたのアイデンティティをそれぞれのオペレーティングシステムに紐づけたいと考えています。それらのデバイスでの「ハッピーパス」は、AppleまたはGoogleアカウントに紐づけられた同期パスキー管理を使用することです。もしそれらの自動システムが、ある日あなたのアカウントを禁止すると決定した場合(別タブで開く)、サードパーティアカウント全体で使用されているすべてのパスキーへのアクセスも不可逆的に失われます。

FIDOアライアンスは相互運用性の向上とパスキーのエクスポートの容易化に取り組んでいますが、プロバイダー間のエクスペリエンスは依然として断片的で一貫性がありません。これは今後数年間で改善される予定ですが、現時点では依存するには未熟すぎます。必要に応じて手動で簡単にエクスポートできる文字列であるパスワードと比較してください。

サードパーティ製同期パスキー

Bitwarden(別タブで開く)やKeePassXC(別タブで開く)のようなパスワードマネージャーにパスキーを保存する場合、プラットフォームと戦うことになります。オペレーティングシステムは最近、サードパーティツールが連携するためのAPI(AndroidのCredential Manager(別タブで開く)など)を導入しましたが、エクスペリエンスは断片的であり、パスワードの自動入力に向けた数十年のUXの洗練さには欠けています。ブラウザ外やネイティブアプリケーション内での自動入力は、特に一貫性がありません。将来的には、サードパーティ製パスキーが前進する道だと信じていますが、まだそこには到達していません。

パスキーが機能しない場合

パスキーの理想的なシナリオは、自分が所有するデバイスでアカウントにログインすることです。同僚のコンピューターを扱う必要がある場合、それははるかに不便になります。ハードウェアキーを接続することもできますが、ポートにアクセスできるとは限りません。同期パスキーでログインすることもできますが、それにはコンピューターが他のすべてのパスキーを漏洩させないことを信頼する必要があります。最後の選択肢は、「ハイブリッドトランスポート」(別タブで開く)を使用することです。これはQRコードをスキャンし、同時にBluetooth経由でコンピューターに接続するというものです。このオプションは安全で理論上は機能しますが、現実は接続が失敗したり、Bluetoothが完全にサポートされていなかったりするエッジケースに悩まされています。

パスキーはまだ準備ができていない

エンタープライズユーザーがパスキーを使用する正当な理由があると信じていますが、個人向けのイ​​コシステムはまだ十分に成熟していません。

TOTPコードには既知のフィッシング脆弱性がありますが、パスキーのリカバリとロックアウトのリスクは、ほとんどの人にとって、AiTMプロキシ(別タブで開く)よりも日々のリスクの方が大きいと筆者は述べています。サードパーティ製パスワードマネージャーに保存されたランダムに生成されたパスワードと、独立したTOTPアプリの組み合わせは、プレーンテキストの柔軟性を犠牲にすることなく、ユーザーにコントロールを与えます。以前はすべてのサイトでパスワードを再利用していたユーザーにとっては、パスキーは大きな進歩です。それ以外の人々にとっては、現時点では一歩後退です。