去る10月12日に、田町のマネーフォーワードでidcon vol.29 が開催されました1。
以下、リアルタイム tweet していたもののまとめです。
Android & Chrome 上での Passkey 実装について by @agektmr
プレゼンテーション概要
- 1) passkey は password を置き換える技術。２段階認証なども置き換える。2) ローカルで認証できる。生体認証はネットワークに送られない。3) 作られたpasskeyはデバイス間で同期される
- Passkey は Google, Apple, Microsoft 三社の協調した取り組み。
- passkey のここがすごい：
- 技術は @FIDOAlliance と W3C の WebAuthn WGで標準化されている
- それ自体で２要素認証。所有＋Knowledge or Inheritance
- フィッシング攻撃耐性がある。passkey はドメインに紐付けられている。
- 普及すればパスワードが要らなくなる。公開鍵だけがサーバにあるので漏れてもリスクは低い
- デモ
- この例ではUse your screen lock という表示で生体認証で入る。
- Google の #passkey は discoverable credentials で実装Appleの場合はFIDO Credential を作ると全部 passkey。
- Passkey の範囲が会社によって微妙に違う。apple は #fido credential 全部。Google はデバイス間で同期されるものだけを passkey という。Google password manager で同期される。
- 同期されることがブレークスルーである理由：以前はローカルデバイスに紐付いていたので別の端末に行くと使えなかった。旧端末でログインするか、SMS認証するかとかしなければならなく、100個デバイスがあると…。
- Device unlock のコードで同期される。Google play services が必要。Android上であれば、Google Password Manager に対応すれば #passkey を使用可能。
- Google password manager は、Mac/iOS/iPadOS/windowsでは使えない。Android でしか使えない。Apple ecosystem では icloud keychain を使う方向だが現段階ではAPIが無い。
- Googleはサードパーティのパスワードマネージャを使うこともできるようにする予定
- おすすめの #passkey UX
- 1) Form autofill – password も使っているユーザも考慮するとこうすればシームレスにログインできるようになる。ConditionalUI。ユーザが最初にログインした直後にpasskeyを作る。
- 2) エコシステムマタギの場合には、caBLE→Hybrid に名称変更されたモードを使う。QRコードを表示してスマホでスキャン。BLEで近接認証しているので、QRコードをどこかに送ってもそれではログインできない
- Device public key – デバイスに紐付いていた前提が崩れているがそれは良いのかという疑問に答えるために定義された。WebAuthのExtension。Appleは対応する予定はない。Androidはサポート。ただし、attestationは当初サポートしない。
Q&A
Q. #passkey の同期はまさか秘密鍵を？
A. YES。暗号化して。＜質問者の方「大胆だなー」
Q. E2EEをどうするの？
A. わからない。
Q. Conditional UI と 別の端末を使ってhybrid を使おうとするとアカウントが見つからないのでは？
A. 改善の余地あり。Appleのアプローチは良いのではないか。
iOS, iPadOS, macOS 上での Passkey 実装について by @nov
プレゼンテーション概要
- iOS16+, iPadOS16+ (今月末), macOS13+ で #passkey 使える。
- もともと #passkey が発表されたのはWWDC21。かんたんさをアピールしていた。
- Always with you (if you only use Apple devices)
- Passkey + Autofill = new WebAuthn UX。10年くらい #fido やってるけど誰も使わない。セキュリティはみんな気にしない。多少セキュリティが落ちてもUXが良くないとだめ、ということ。
- デモ
- ブラウザーからQRコードを使ってiPhoneを鍵にしてログイン。
- QRコードの下にyubikeyを呼び出すリンクもあるが、conditional UI は yubikey を使う人には良くない。
- passkey の同期は数秒でできた。
- 解決された問題：
- Appleのデバイスを持っている人は同期される
- emailフィールドのfillin, パスワードのfill-in と２回faceidしていたのが１回ですむ。
- 解決されていない問題：
- Discoverable credential に入っている email address のアップデートはW3Cで議論されているが今は解決されていない。
- 再認証で conditional UI を使いたい場合。Conditional UIの場合、どの鍵を使えという指定ができない。そのため、password fill-in に複数の候補が出てしまう。これは、仕様にマージされた。
- サインアップをオートフィルでやるのはどうするか。パスワードだとパスワードマネージャが勝手にやってくれる。なんとかしてほしい。
- ３つのプラットフォームをまたがる場合の解決ができていない。その観点ではそんなに game changer ではない。
- Apple では icloud keychain が disable されていると、fido credential がそもそも作れない。会社端末ではdisableされている。どうせいというのか。＜ただし、Roaming Credential は使える。
- POST /.well-known/change-password みたいに、POST /.well-known/webauthn-credentials ができたらユーザは気づかないうちに目的を達せられるのでは
Q&A
Q. icloud keychain が disable されている場合はYubikeyなどを使えということか？
A. YES。iPhone使うか、Roaming credential を使え。（でも、大変だからパスワード使えというのがAppleの答えと思う。）
ヤフーの WebAuthn UX の紹介と Passkey 対応 UX の考察 by YumejiHattori (@kura_lab の後輩)
- YJの認証は２画面認証 (identifier first pattern) になっている。IDにFIDOが登録されていると、２画面目に行くと自動で WebAuthn が発動する。この場合、credential が登録されていない端末では失敗ダイアログが出てしまう。
- これは、credentials.exisits (credentialId) をSuperCookie として使われてしまうなどの理由で FIDO ではサポートしていなかったことに起因。
- これを回避するために、OSによってクレデンシャルが存在するかの推測をしている。
- passkey 登場による課題1。 #iOS: 登録済み #MacOS: 未登録の場合、#webauthn が発動しない。
- authenticatorData.flags に含まれるフラグ BackupState (BS) があると、iOSとMacOSでは同期されている可能性がある。そのため、MacでもWebAuthn発動できるようになる。
- Passkeys登場による課題(2) ハイブリッド(caBLE)のサポートをしていないことに起因する課題。iOSを使ってWindowsでログインすると、Windows:登録済み iOS: 未登録になってしまう。
- サービス側でユーザにWebAuthnをサジェストしたいが…。
- Passkeys へ完全対応するための方法の例：
- ユーザによる認証方法の選択必須課（例：GitHub）めちゃめちゃ目立つように「生体認証を利用」が出てくる。しかし、大半のユーザはその利用可否に関わらずこのボタンを押してしまって「がっかり体験」
- Conditional UI を使うと、クレデンシャルが存在する場合はTouch IDが選択肢に出る。存在しない場合にはPWおよび別のデバイスを使って… がでる。これは、まさにやりたかったことだが
- Conditional UIの課題
- サービス側のクレデンシャル削除時の挙動：端末では利用できるがサービス側が受け付けなくなる→ガッカリ体験
- これらを踏まえたベターなUXはどうあるべきか。
- if 再認証ユースケース：Cookieの認証履歴等でWebAuthn自動発動
- elseif: 新規ログイン: Conditional UI
- else: WebAuthnが成功する可能性が低いので(消極的, hybrid含む)WebAuthn選択画面
Q&A
Q. Hybridを使ってiOSを使ってWindowsからログインした場合に、iOSを使ってきたというのはわからないのか？
A. Hybrid 経由で登録する場合にはわからない。Appleはあえてわからないようにしている。
Q. 一旦SMSにfallbackしたユーザをWebAuthnに戻したい場合はどうする？
A. 確認コードの認証画面でWebauthnを登録してもらう、かな。
Q. RP側でオペレーションが走ってクレデンシャルが消された場合はパスワードでも同じ。パスワードの場合は変更するとPassword Manager に反映される。Passkeyの場合は？
A. Androidの場合は同じユーザハンドルで新しいクレデンシャルを作ると上書きされる。(by @agektmr )
Q. AirDropはサブスクを共有するのに使われてしまうのではないか。
A. Netflix など多くのサイトでは家族間では共有されるので、こうした場合は問題ない。
全体Q&A
Q. Airdrop phishing はありえないか？
A. お互いに連絡先に入っていないとできないが、突破される可能性はある。
Q. Passkeyという言葉が enduser向けに使われていくのか？今のUXは各社でバラバラ。
A. まだ表では使っていないが、helpなどでは使っている。
Q. email field で passkey 聞かれ、password field でも聞かれることが起きる。プラットフォームで対応時期がバラバラ
A. Reverse bruteforce を考えると…
Q. Reauthenticationのとき、#passkey に対応すると、platformの乗っ取りリスクに依存してしまうがRPはどう考えているか？
A. リスク的に耐えきれないなら使わない。＜某米国金融機関はぐえーっと言っていた (by @_nat)。
Q. コンシューマ向けではattestationは無い前提？
A. 某社的には無い前提。
Q. 悪意を持っているauthenticator の場合、attestationが無いとごまかしうるのでは？
A. 理論的にはyes。
A2. 米国で某PFベンダーがattestation使ってるところがないということを言っていた。実はあるけど。
A3. もともと紳士協定のもとで信用できるということだったのが、今回明示的に信用できないということになったということでは？
Q. Passkeyですか? passkeys ですか？
A. password/passwords と同じ扱い。
A2. ちなみに、better password 、password manager で管理されていることがわかるパスワードと考えれば良い。