ベンダーロックの部分について詳しく教えてくれる？パスワードマネージャーにパスキーを保存してるから、結構ポータブルだと思ってるんだけど。各サービスがユニークなパスキーを要求するってこと？それって、各サービスが自分のTOTPシードを必要とするのと似てるよね。

私にとって、パスキーが実用的なのはクラウドにバックアップして、デバイス間で自動的に同期できるからだけ。そうじゃなきゃ、全然信用できない。

どうやってベンダーロックインを打破するつもりなのか、いつも聞いてるんだ。結局、自分を認証するための秘密を使ってるわけでしょ。ベンダーが管理してるパスキーだと、そのベンダーに秘密を管理してもらうことになる。もしそのベンダーが秘密を他の誰かに渡せるなら、誰がその秘密を知ってるか確認できなくなるよね。秘密を広めるプロトコルを考えられるかもしれないけど、それだとみんなのコミュニケーションの負担が増えるだけだと思う。もっと賢い人が驚かせてくれるかもしれないけど、歴史的に共有できる秘密は長くは秘密じゃないよね。

自分のYubikeyをaccount.google.com（他のウェブサイト、例えばfastmail.com）でパスキーとして登録できるよ。アカウントのセキュリティページ[0]に行って「可能な場合はパスワードをスキップ」を有効にすれば、Yubikeyを使ったパスキーだけでGoogleにログインできる。Yubikeyに古いGoogleのクレデンシャルがある場合は、まずそれをアカウントから削除しないといけない（古いプロトコルと新しいプロトコルがあって、古いプロトコルが有効だとGoogleはパスワードなしのログインをサポートしないから）。バックアップが欲しいなら、複数のYubikeyが必要だよ。キー間の同期はないからね。サポートマトリックスについては[1]を見てね。[0]: https://myaccount.google.com/security [1]: https://passkeys.dev/device-support/

Androidでは、Keepass2Androidの開発者が近い将来にパスキーをサポートするために取り組んでるみたい（https://github.com/PhilippC/keepass2android/issues/2099）。正直言うと、パスキーについて十分な時間をかけて学んでないから、そのアプリがすべての実装をサポートして、ベンダーロックを完全に避けられるかは確信が持てないんだ。

FIDOアライアンス（W3Cと一緒にWebAuthn仕様を書いたところ）が、パスキーや他の認証情報を移行するためのフォーマット（Credential Exchange Format）とプロトコル（Credential Exchange Protocol）のドラフト仕様を持ってるよ。[1] まだどのプロバイダーも実装してないと思うけど、取り組んでるみたい。[1] https://fidoalliance.org/specifications-credential-exchange-...

1Passwordは、iPhone、Mac、Linuxボックスのすべてのパスキーと統合されてるよ。私にとっては、サブスクリプションの価値があるって感じ！

この件に関する標準の状態を知ってる人いる？キーのエクスポート/輸送は実装者の任意みたいだけど、私の解決策はBitwardenを使うことだから、少なくともクロスプラットフォームのキーが手に入るよ。

自分はBitwardenを使ってパスキーを保存してるよ。すべてのデバイスに同期されて、普通に動くし、問題もほとんどない。ほんとに心配性の人は、自分のサーバーでオープンソースのバックエンドを運用することもできるよ。https://bitwarden.com/passwordless-passkeys/

あんまり使わないな、登録してデバイスエコシステム間で使う良い方法がないから。3つのOSを定期的に使ってるよ。

そうだね

全体的な統計はないけど、iOSにすごく統合されてるよ。パスキーが何かも知らずに使ってしまうこともあるかも。ウェブサイトやアプリが「パスキーを追加」って促してきて、受け入れを押すとパスキーがもらえて、他のAppleデバイスに同期されて普通に動くんだ。

1Passwordがボールトのパスキー解除を早くリリースしてくれるといいな。そうすれば、もうパスフレーズを入力する必要がなくなるし、俺の「パスフレーズ」は実質的に携帯電話の解除コードになるんだ。

まだ主要なブラウザやオペレーティングシステム（例えばLinuxのChrome）では実装されてないから、あまり普及しそうにないね。

Linux、macOS、Windows（10と11）でChrome、Firefox、Safariを使って大きなウェブサイトで使ってきたよ。Githubやいろんなサービスの2FA、地元のスーパー（アルバート・ハイン）などのウェブサイトの主要なログインとしても使ってる。自分のKeycloakサーバーに認証するためにも使ってるんだけど、これはネットワーク内のいろんなサービスを守る役割を果たしてる。サポートはまだまだ普及してないけど、確実に良くなってきてる。残念ながら、CTAP2のようなプロトコルはLinuxでは実装されてないみたいで、プロプライエタリなOS（指紋認証やタッチIDみたいに、デバイスを手動で追加する必要がない）で超便利な「電話でログイン」プロンプトが欠けてるんだ。

現時点では、できるだけ避けるつもりだよ。コンセプトが嫌いなわけじゃないけど、強力なパスワード＋2FAで十分だと思ってるから、設定に複雑さを加える必要はないんだ。フィッシングはあまり怖くないよ。

うん/ううん。いくつかのパスキーが自分のボールトにあるけど、同じ会社の異なるアカウント用のがいくつかあるんだ（例えば、AmazonやGoogle）。普及は続くと思うけど、何年もかかるだろうね。

パスワード/TOTPはフィッシングから守ってくれないよ。フィッシングサイトは、実際のシステムに入力したパスワードとTOTPを転送してアクセスを得ることができる。FIDO/WebAuthn/パスキーはフィッシングから守ってくれる。記事に書かれているオリジンバインディングのおかげで、フィッシングサイトでは必要な認証情報を生成できないから、どんなに説得力があっても、誤って認証情報を渡すことはない。フィッシングはこれらのシステムが防ごうとしていたものだよ。もし、ハードウェアキーに結びついたプレーンFIDOから、Googleアカウントに結びついたパスキーへの移行がロックインの策略だと言うなら、ちょっと同意するかもしれない。

数年前、ここでパスキーを使わない方がいいっていう投稿がいくつかあったけど、その時はそれに従ってた。でも、今はパスキーが大好きになった。1Passwordと一緒に使うのがすごく楽しい。いつか1Passwordを使うのをやめたいかもしれないけど、まだ全部のパスワードがそこにあるから、戻ることもできるし。正直言って、1Passwordにあるサイトの中でパスキーが使えるのはほんの一部だけなんだ。もっと嫌なのは、パスワードがなくて、毎回メールでログインしなきゃいけないサイト。マジでイライラする。

パスキーはパスワードマネージャーを使う必要があるAPIだよ。ハードウェアに縛られることはないし、パスワードマネージャーを使ってるのと同じくらい自由だね。パスキーを別のパスワードマネージャーにコピーすることはできないけど、同じアカウント用に新しいのを作ることはできるから、だいたい同じくらい便利だよ。

俺はYubikeyをパスキーとして使ってるんだけど、セキュリティの面ではパスワードよりもずっと優れてるよ。> でも、Bitwarden以外はエクスポートをサポートしてるところがほとんどないみたい。これって無意味に思えるけど、インポートをサポートしてるプラットフォームは知らないんだ。未来には変わるかもしれないけどね :-)。技術的には可能なんだから、いいことだよね？

仕事でパスキーを実装したんだけど、最初は技術部門だけに展開したんだ。誰もちゃんと動かせなくて、トラブルシューティングはほぼ不可能だったよ。できることと言ったら、パスキーを消してもう一度やり直させるくらい。今はパスキーのサポートを無効にしてて、近いうちに再展開する予定もない。成功裏にパスキーを展開したのは、実質的にユーザーサポートがゼロの会社だけで、そういうところはパスキーを全くサポートしないから、特定のユーザーにうまくいかなくても「まあいいや」って感じ。TOTPは完全に展開されてて、しっかりサポートされてる。トラブルシューティングは「難しい」けど、少なくとも可能だよ。TOTPのトラブルシューティングは基本的に3つのことに集約される：* サーバーの時間 * ユーザーの電話/デバイスの時間（ほとんどのユーザーは電話でTOTPを生成するけど、そこは気にしない） * 特定のサイトのために保存されたTOTPが1つ以上あるか（つまり、古いのを置き換えずに新しいTOTP共有キーを作った）または全く保存されていないか。うちの技術/ユーザーサポートヘルプデスクはこれに対応できるけど、かなりのトレーニングが必要だった。特別なツールも作ったし、複雑さに圧倒されるとリクエストが来ることもある。パスキーのトラブルシューティングは：* モバイルネットワーク、Bluetoothを含む * サーバーネットワークの接続 * コンピュータ/デバイスネットワーク、モバイルデバイスへのBT接続を含む。ほとんどのテクニカルサポートは、一度にこれだけの複雑さを扱えないよ。実際、ほとんどの開発者やテクノロジーの「天才」たちもそうだし。運が良ければ得られるエラーメッセージも、非常に一般的で全然役に立たない（最後に確認したときはそうだった）。パスキーは、ユーザーをサポートしなきゃいけない環境では現在は適していないと思う。いつか良くなることを願ってる。1Passwordは、ほぼ確実に動くパスキーの唯一のクライアント/デバイス実装だね。パスキーを1pボールトに保存して、1pボールトはデバイス間で同期できる。

1PasswordとFirefoxを使ってMacOS、iOS、Windowsでパスキーの同期や使用に問題はなかったよ。サイトがパスキーを作成または使用したいときは、使っているデバイスで1Passwordからプロンプトが出る。セカンドデバイスを使う必要もないし（セキュリティ的にはそれで全然大丈夫。もし本当にマルウェアがキーを抜き取る心配があるなら、Yubikeyを使ってるだろうけど）。

どんなMacを使ってるの？MacOSのバージョンは？数年前にパスキーを試したとき、古いMacで生体認証のハードウェアサポートがなかったから、QRコードを使って携帯電話を使う必要があったのを覚えてる。それ以降は、そのサポートがあるMacを手に入れたら、パスキーの作成が完全にMac上でうまくいってるよ。

ちなみに、俺はYubikeyのFIDO2認証情報を使ったed25519-sk SSHキーに移行したんだけど、すごく気に入ってる。自分の認証情報がハードウェアキーから取り出せないっていうのは、かなり安心できるよね。

KeepassXCを見てみて、バックアップができるよ。

物理キーとの相性は最高だよ。家に置いておくバックアップ用の1つがあれば十分。

これはよくある質問だけど、すごくシンプルな答えがあるよ。彼らはまだ回復方法を持っている。ほとんどのプロバイダーでは、オプションでこれを変更できる（アカウント設定に入って、回復コードみたいなものを設定して、完全にパスワードなしにするオプションをチェックする）けど、いずれにしても回復方法はある。例えば、電話を失くして、セカンダリメールと古いパスワードの組み合わせでアカウントを回復したことがある。あなたは「でも、回復方法があるなら、私のアカウントはそれと同じくらい安全じゃないの？」と主張するかもしれないけど、パスキーを使うことで、日常的にパスワードを入力しない分、ずっと先に進んでいることを指摘したい。回復方法も二要素になることが多いけど、パスキーはその2つの要素のうちの1つではない（つまり、メール+パスワード）から、いずれにしてもパスワードだけよりも勝ってる。パスキーは、古い二要素認証器と同じように考えるべきだよ。要するに、デバイス（例えば、あなたの電話）がハードウェアセキュリティキーとして機能する最新のFIDO標準ってことだから。これらはすべてのプロバイダーでアカウント回復の方法を持っていたよ。

複数のパスキーを持てるようにしてほしいな。デバイスごとに1つずつね。

CTAP2を使えば、どんなWindowsノートパソコンでもパスキーを認証できるよ。macOSもそこそこサポートしてるけど、iPhoneを使ってないとちょっとスムーズじゃないね。俺は何かのためにWindowsを起動する必要があるときに、Bitwardenアプリを使ってパスキーのログインをノートパソコンに表示させてる。基本的に、システムがキーを選ぶように促してきたら、「電話でログイン」ボタンをクリックして、電話のロックを解除して、アカウントを選択/「OK」をクリックして認証するんだ。最初にこれをやるときは、QRコードをスキャンして電話をコンピュータにペアリングする必要があるけど、その後は必要なときに電話を使えるよ。Linuxのパスキー（おそらく*BSDのようなニッチなシステムではもっと）には愛が必要だね、特にCTAP2に関しては。Chromebookがそのネイティブサポートを持ってる唯一のLinuxデバイスかもしれない。火事から守りたいなら、エクスポート機能があるパスキー提供者（つまりBitwardenやKeepassXC）を使って、そのエクスポートをパスワードデータベースファイルと同じように扱えばいいよ。

普通は対称暗号化キー（AES-256が一番一般的）をパスワードKDFから派生させるんだ。GoogleやAppleが具体的に何をしてるかは分からないけど、これが私の最初の推測だね。

不安定な媒体上で機密チャネルを確立するには、例えばDiffie-Hellman鍵交換を使うことができます。MITM攻撃から守るためには、アウトオブバンドのQRやBluetoothを使うことができます。

ブラウザはログインや登録がどのインターネットドメインに関するものかを知ってるからだよ。それに、ブラウザは認証器とやり取りするためのJavaScript API（navigator.credentials.createやnavigator.credentials.get）も提供してるんだ。

ちょっと前に面白いKickstarterがあって、DiceKeysっていうのがあったんだ。https://www.crowdsupply.com/dicekeys/dicekeys これはパスキーのシードを物理的に保存する仕組みを提供してたんだよね。もしカスタムシードをサポートするパスキーを買ったら、そのシードを必要なだけ複製できるんだ。セキュリティには常にトレードオフがあるけど、これは現実世界に115ビットのエントロピーを持つ何かを保存するための仕組みだったんだ。

なんで根本的に悪いアイデアなの？俺には結構いいアイデアに思えるけど。

確かにそうだけど、TOTPはパスワード漏洩に対して防御してくれるから、パスワードだけを使うよりはまだ安全だよ。

アカウンタビリティシンクについての話だね。2つ目の要素を要求する目的は、ユーザーがハッキングされたときに会社がユーザーを責めるためなんだ。実際のセキュリティとはあまり関係ないよ。

その通り、ステファン！俺もそのために別々のボールトに保管してる。まだパスキーには賛成できてないけど、ここでの議論を聞いてるとBitWardenが一番の解決策に思えるね。

TOTPを使うと、パスワードとは違って、送信しないプライベートキーがあるから、セキュリティが向上するんだ。パスワードとTOTPが同じボールトにあってもね。

確かにそうだね。でも、多くの人は実際の2FAを使いたがらないか、その意味を理解していないんだ。ボールトがちゃんとセキュリティされていれば（実際のMFAで）、ウイルスに感染するまではあまりリスクはないはずだよ。

俺にとっては、これって完全に脅威モデル次第だね。一般的に、ワンタイムパスワードは、誰かがウェブサイトに行って入手した認証情報（例えば漏洩から）を使ったり、ブルートフォース攻撃を防ぐための追加のセキュリティ対策なんだ。攻撃者は2つ目の要素が必要になる。もしパスワードマネージャーに2FAの秘密をパスワードと一緒に保存していれば、これらの攻撃からの保護を得られるし、すごく便利だよ。ただし、攻撃面も広がる：もしパスワードマネージャーに侵入されたら、終わりだね。もし脅威モデルが許すなら（俺のは許す）、これはまだ非常に安全で、しかも便利だよ。

そうだね、これは二段階認証じゃなくて二要素認証だね。ちょっとセキュリティは落ちるけど、便利さはかなり増す（この二つの間の古くからのトレードオフだね）。パスワードだけの時と比べての利点は、今は静的じゃなくて時間ベースになったことだよ。

昨日、友達が似たような質問をしてきたんだけど、答えはわからないけど、そうなってほしくないな。ほとんどの大きなウェブサイトはCDNやロードバランサーの背後でホストされていて、TLSセッションを終了させて、顧客と実際のバックエンドサーバーの間でMITMになってるんだ。この問題はTLSクライアント証明書と似ていて、今はバックエンドにこれを転送できないし、ロードバランサーはデータを検証するほど賢くないから、使うのは不可能なんだ。最近の数年（約5年）、AWS ALBや競合他社がクライアント証明書のサポートを得て、証明書情報をHTTPヘッダーでアプリケーションに渡すようになったんだけど、クライアント証明書を標準化された方法で読むのではなく、サーバーは非標準のヘッダーから読む必要があるんだ。もしパスキーもHTTPペイロードとして渡されるなら、LBがペイロードを読むのはすぐには無理だと思う。IaaSではできないことを、Auth0みたいなIDP-as-a-serviceの売りにするかもしれないね。