パスワードを超えたその先に

♪ （パスワードを超えたその先に） こんにちは Garrett です Authentication Experience チームのエンジニアです 今回は私たちが 取り組んできたことを 皆さんにご紹介することができて とても嬉しく思います Appleは業界全体の パスワード離れを サポートするために 最初の一歩を踏み出しました 現在AppやWebサイトに サインインするたびに パスワードを入力していることが 多いでしょう ユーザー名とパスワードという フィールドの組み合わせは すぐに認識でき非常に使いやすく ほとんどの人はそれに 出くわしたときに 何をすべきかすぐにわかります しかし開発者 ユーザー 及び業界全体は アカウントにサインインするために 迅速に認証できるという この優れた利便性に伴って アカウントのセキュリティが 犠牲になることを学んできました 認証技術は長年にわたって 進化してきましたが 業界が学んだ 基本的な教訓がいくつか あります まず第一にシークレットを守ること は難しいです 特にシークレットが 共有されている場合は難しい 現在ほとんどの認証は アカウントの作成時に ユーザーとサーバがシークレット たとえばパスワードを共有し 認証のたびにそのシークレットを 再共有することになります そのシークレットが 共有されるたびに 意図した受信者以外の誰かが そのシークレットを知ってしまう というリスクがあります 偽の電子メールや電話 誤解を招くWebサイトなどの フィッシングは 犯罪者がシークレットを知るための 最も一般的な方法です そしてパスワードのような シークレットが流出した場合 脆弱なパスワードを使用したり 複数のアカウントで同じ パスワードを再利用したりすると 問題が急速に悪化する可能性がある 2020年の 「Verizon Data Breach Investigation Report」 によると ハッキングに関連するデータ漏洩の 80%以上が 認証情報の不正利用や 認証情報の紛失や盗難 によるものだったということです 実は この方法でなくても問題ありません 認証技術は これらのリスクを軽減するために 進化を続けています 当初パスワードは主に 人の頭の中に保存されていました しかしユーザーは一般的に すべてのアカウントに対して 堅牢でユニークなパスワードを 思い付いたり、覚えたりするのが あまり得意ではありません そこでパスワードマネージャーは アカウントごとに堅牢でユニークな パスワードを作成でき フィッシングの可能性のある形式に 関するヒントも提供する可能性があります iCloudキーチェーンの パスワードマネージャーは Appleデバイスに 組み込まれており サードパーティは自分の独自の パスワードマネージャーを システムに統合するためのAPIを 利用できるようにしました サービスオーナーは パスワードに加えてOTPなどの 追加要素を要求するなど ログインフローに追加の手順を 追加することもできます たとえばSMSや 生成されたワンタイム認証コード などです macOS Monterey とiOS 15には iCloudキーチェーンの パスワードマネージャーに コードジェネレータが 組み込まれているので 詳しくはチームメイトのエリン のビデオ 「iCloudキーチェーン 認証コードによるセキュアなログイン」 を見ていただきたいです AppやWebサイトによっては Appleでサインイン などの フェデレーション認証を通じて 第三者に認証を 完全に委託する場合もあります フェデレーション認証を使用すると 信頼を高度に保護された 少数のアカウントに限定できます しかしこのビデオでは 非フェデレーションの 認証オプションに焦点を当てます これらを比較してみましょう これらはどれも非常に使いやすく ほとんどのデバイスで機能し 多かれ少なかれ常にユーザーと 共に使用されます しかしセキュリティレベルは もっと良くなることができます 覚えやすいパスワードは 恐らくすべてのアカウントにとって 堅牢でユニークではありません パスワードマネージャーは 堅牢でユニークなパスワードを 作成するために使用できますが パスワードを保護するために 使用するパスワード --および場合によっては 追加の要素-- と同じくらいの堅牢性です また 使い捨てのコードも役に立つが 依然としてパスワードと同じく 多くの問題が発生します それは入力可能で フィッシング可能で共有 されているシークレットだからです またパスワードが頭の中にあれば それを忘れることもあります これはAppとWebサイトは別の リカバリフローを必要とすることを 意味しており 現在では通常 電子メール内のリンクを指します これによりアカウント全体 のセキュリティレベルを Eメールプロバイダのセキュリティ レベルにまで下げられますが 通常は管理するものではありません 一部のパスワードマネージャーと ２要素付きのソリューションは リカバリに役立ちますが 同様の問題に直面する傾向があります 記憶されているパスワードも フィッシング対策にはなりません パスワードマネージャーは フィッシングに関する ヒントを提供することができます たとえば フィッシングサイトで パスワードを入力しないように 指定できます ただし、誰かが手動で パスワードを入力して フィッシングされるのを 防ぐことはできません ワンタイムコードにも同じような 問題がありますが 現代的な 緩和策もいくつかあります そして最後に これらの方法はすべて ユーザーとサーバ間の共有 シークレットに依存しているため 基本的に その共有シークレットの 最も弱い保護よりも 強力ではありません この表を念頭に置いて パスワードの問題に対する 実際のソリューションの プロパティについて説明します まず パスワードの置き換えは 設計上安全である必要があります すべてのベストプラクティスに 従えば パスワードはかなり安全になります しかし これまでの経験では 誰もが常にそれをできるのは かなり難しいことがわかりました パスワードの置き換えでは 最初からセキュリティを 構築する必要があります しかし私たちはユーザビリティを 後退させたくもありません パスワードは非常に使いやすく 長い間使用されてきましたので それを失いたくありません 簡単であることには 常に利用可能で そして どこでも使用可能ということが 含まれます 現在では自分のパスワードを 知っているか もしくは検索できる限り サインインしたいデバイスがその パスワードを認識し保存 していると考えることができます 新しいデバイスで認証を行う際に 摩擦が生じるようなことがあれば すぐにサインインしたいユーザー の利用を妨げることになります そして最後にリカバリは後から 追加されるものではなく ファーストクラスの機能である 必要があります 人は間違いを犯したら 悪いことが起こり パスワードの解決策は 全体的なセキュリティを 損なうことなく 人間である人間を扱うのに 十分な耐障害性を持つ必要があります 現在存在する最も強力な セキュリティオプションの1つは セキュリティキーであり ハードウェアドングルまたは フォブは特に 高度なセキュリティのコンテキストの中で ２番目の要素として一般的に使用されます これらは 誰もが利用できるWeb認証 つまり WebAuthn 規格に基づいています そして それらのほとんどは 最初のラーニングカーブの後で 非常に使いやすいです しかもパスワード だけよりも遥かに安全です この強みの大半はWebAuthn によるものであり これについては後ほど 詳しく説明します 最新のWebブラウザも 最新のほとんどのデバイスで セキュリティキーを サポートしています macOSとiOS上の Safariはしばらく前から USB NFC Lightning のセキュリティキーを利用できています 多くのセキュリティキーは複数の 接続方法もサポートしているため 1つのハードウェアキーを様々な デバイスで使用できます WebAuthnとパスワードを 比較してみましょう WebAuthnの 最大のメリットの1つは パブリックキーとプライベートキー のペアWebAuthnが 共有シークレットの代わりに 使用されることです 現在のパスワードの動作を 確認する場合は まずパスワードを入力します その後 通常は ハッシュとソルティングなど によって難読化され 生成されたソルテッドハッシュが サーバに送信されます サーバのコピーは 難読化されていますが ユーザーとサーバの両方が シークレットのコピーを 保持しており そのシークレットを保護する責任は ユーザーにもあります これは私たちが解決できるものです パブリック/プライベートキーの ペアを使用すると デバイスはパスワードの代わりに キーのペアを作成します これらのキーの1つは公開キーです ユーザ名と同程度公開されています これは誰とでも共有でき シークレットではありません もう1つのキーは プライベーキートです プライベートキーはシークレットで デバイスによって保護されています デバイスがこのキーを他のユーザー と共有しないほか サーバと共有する こともありません アカウントを作成すると デバイスはこれらの2つの 関連キーを生成します 次にサーバにパブリックキー を共有します これでサーバにパブリックキーの コピーが作成されました パブリックキーはパブリック情報 であるため パスワードと同じ 保護要件はありません プライベートキーはデバイス上 に残り そのデバイスだけが保護の 責任を担います 後でサインインするときに サーバにシークレット情報は 送信されません 代わりにデバイスがアカウントの パブリックキーに関連付けられた プライベートキーを 認識していることを証明することで 自分のアカウントであることを証明します そのやり取りはこのように 動作します まず自分のアカウントに サインインします その後Webサイトは自分の デバイスに それが実際に自分のアカウントで あることを証明するように要求します これはいわゆる 「チャレンジ」 を実行して デバイスがアカウントの パブリックキーと関連付けられた プライベートキーを持っている ことを証明することによって行われ プライベートキーが何であるかは 実際には示されません そのためにサーバは使い捨て チャレンジを送信します デバイスはプライベートキーを 持っているので このチャレンジを実行し プライベートキーを使用して チャレンジの 「サインイン」 と呼ばれる処理を行います 自分のプライベートキーだけが 自分のアカウントに対して 有効な署名を作成できます そしてこの署名はサーバに 送信されます サーバはすでに パブリックキーがあるため この署名をその パブリックキーと照合します パブリックキーを持っていれば 署名がそのキーに一致するかどうか 簡単に確認できます 但し プライベートキーを 持っているのは自分だけなので チャレンジに対して有効な署名を 作成できるのは自分だけです 従って 私のシークレットが 何であるかを確実に知ることなく 誰でも簡単に私の身元を 確認できます そして最後に サインインしているユーザーの署名 が実際にパブリックキーと一致する 場合 サーバはサインインして いると通知します プライベートキーがデバイスから 削除されないことに注意願います サーバはこれが自分の アカウントであることを 私のシークレット つまり プライベートキーを知ることなく 確認できます 実はそうなのです

パブリック/プライベートキー のペアは 認証情報がデバイスによって 作成および管理され プライベートキーがサーバと 共有されることはないため これらのキーは推測されたり 再利用されたり 脆弱であったり サーバに侵入される脆弱性が あったりすることはありません WebAuthnはまた 人間ではなく ブラウザとOSに信頼を 置いています このソフトウェアは 認証情報が作成されたWebサイト およびアプリケーションでのみ 使用可能であることを 厳密に規定し 不正なWebサイトで認証を 試みることさえ防止できます また WebAuthnの すべての認証情報は パブリックキーとプライベートキー のペアであるため サーバのWebAuthnは 認証シークレットを維持する責任を 負いません これは サーバ側でシークレット の安全を保護するための 作業が少なくなることを意味し アタッカーが盗む 認証シークレット情報がないため アタッカーにとって サーバの価値が下がります その表の他の項目と セキュリティキーを 比較します 最初のラーニングカーブの後は かなり簡単に使用できます すべてのAppleデバイスと 多くの最新のApple以外の デバイスで動作します しかし彼らは必ずしもあなたと ずっと一緒にいるとは限りません 常に追加のハードウェアを 購入して持ち歩く 必要があります これは導入の障壁となる 可能性があり パスワードに比べて使いやすいという 点で一歩後退しています ただしセキュリティレベルは 非常に優れています セキュリティキーの認証情報は 複数のアカウントにわたって 簡単に推測さたり再利用されたり することができないように保証され OSレベルでフィッシング 対策が組み込まれています しかしこの セキュリティには代償が伴います 認証情報が単一のセキュリティキー に関連付けられている場合 そのセキュリティキーが紛失 盗難 または破損した場合 それらの認証情報もすべて失われます 利用者は 追加のセキュリティキーを購入し 安全な場所に保管し 同時に両方を失うことが ないようにするなど バックアップシステムを 用意しておく必要があります しかし WebAuthnのおかげで フィッシングに対して非常に強い 抵抗力を持ち サーバに保存されたシークレット の必要性はなくなります iOS 14.5ではiOS上の 全のブラウザで動作するように セキュリティキーのサポートを 拡張しました macOS Montereyと iOS 15で 新たに追加されたのはmacOS とiOSのすべての Appで初めて利用できるようになった セキュリティキーAPIです このAPIはWeb上の WebAuthn API に相当するネイティブAPIとして AuthenticationServices フレームワークのASAuthorization APIファミリに追加されています ASAuthorizationは はパスワードや Appleでサインイン セキュリティキーなど システムがサポートする あらゆるメカニズムで サインインできる ワンストップショップです 但し セキュリティキーなどの ハードウェアを追加して 持ち歩くことは必ずしもすべての 人にとって必要なこと ではありません このAPIは ユーザーにとっての使い勝手との バランスよりも 特別な安全性のニーズが 優先されるような 特にセキュリティの高い 状況でのAppに 役立つと信じています 現在キーペアを使用した パスワードレス認証は 認証技術における次の 大きな課題があります この標準はアカウントの セキュリティを 向上させることを目的とし プラットフォームベンダーと サービスオーナーの両方が 業界全体で協力して 取り組んできたものです それはこのビデオの残りの部分で 私が話したいことです そしてここで 私はとても喜んで皆さんに ポストパスワードの世界に対する Appleの貢献のプレビューを ご紹介したいです この新機能はすべての iPhone iPad Mac WebAuthnにセキュリティ を組み込んでおりパスワード に代えて世界中で利用可能です 「iCloudキーチェーンの パスキー」と呼ばれているものです この新機能では「パスキー」 と呼ばれる新しい種類の認証情報が iCloudキーチェーンに 保存されます パスキーはバックアップ同期 およびすべてのデバイスでの 作業の操作性を兼ね備えた 標準で提供された驚くべき セキュリティを備えた WebAuthn認証情報です iCloudキーチェーンに 保存しています iCloudキーチェーンの他の 全のものと同様にエンドツーエンドで 暗号化されているので Appleでも読むことができません シークレットは あなたのシークレットです 非常に使いやすくなっています ほとんどの場合 1回タップするかクリックするだけで サインインできます そしてWebAuthnと iCloudキーチェーンの 組み合わせによるセキュリティの おかげで現在出回っている多くの パスワードと第2の要素を組み 合わせたソリューションよりも強い また1回のタップ操作でサインイン できるため 現在一般的に使用されている 多くの認証形式よりも 簡単 迅速 かつ安全です 表に追加しましょう 先ほど言ったように とても使いやすいです 通常は1回タップするかクリック するだけでサインインできます macOS Montereyと iOS 15の一部として リリースされたものはAppleの 全デバイスで動作します もちろんすべての人の パスワードを置き換えるには iCloudキーチェーンを サポートしていないデバイスも含め すべてのデバイスでこの 技術が使える必要があります この機能は macOS Monterey とiOS 15にはありません すべてのAppleデバイスに 内蔵されているため iPhone iPad またはMacが 近くにあればいつでも利用できます 追加のハードウェアは 必要ありません WebAuthn標準と iCloudキーチェーンの 両方に含まれる高度な保護機能を すべて利用しています iCloudキーチェーン に支えられているため Appleデバイスをすべて 紛失しても 認証情報を取り戻すことができます これは セキュリティキーと同じように プラットフォームが提供する強力な フィッシング耐性を持っています またパブリックキーと プライベートキーのペアを 使用しているため サーバは認証シークレットを 保存する必要がなくなり アタッカーにとっての 価値が下がります これがその仕組みです これは人気の認証デモApp のShinyで ソースコードはこのビデオの 関連リンクにあります まずアカウントを 作成する必要があります ユーザー名を入力して アカウント作成ボタンを タップします 次に信頼されたシステムシートに 認証情報とその使用場所に 関する情報が表示されます 続行 Face IDの順に タップすれば完了です 特に考える必要は ありませんでしたが このアカウントには非常に強力な パブリック/プライベートキー 認証情報があり iCloudキーチェーンに 安全に保存されています このAppに戻って サインインしたい時も 同じくらい簡単です シートが表示されると サインインしているAppの 名前やアカウントなど 非常に明確な質問が表示されます これでいいので続行 Face IDをタップして終了です これで終わりです! これら新しい認証情報を作成して 使用するには これだけで十分です また システムで管理された パブリックキーとプライベートキー のペアであるため 再利用されたり推測 されたりすることはありません AppやWebサイトの 侵害に対して脆弱ではなく オペレーティングシステムと ブラウザには非常に強力な フィッシング保護機能が 組み込まれています ブラウザといえば これらの認証情報は Web上でも機能します ここで私は WebAuthnを採用した Shiny Webサイトの ホームページ上の Safariにいます サインインボタンをタップすると 作成したばかりの 認証情報を使用するか 使いたいセキュリティキーを 使用するか 選択できます ここで続行 Face ID と タップすれば Appと同じように サインインできます これはiOS上のすべてのWeb ブラウザAppでも動作します Macでも使えます！ これらの認証情報は iCloudキーチェーンに 保存されるため すべてのデバイス間で同期され あらゆる種類の Mac Appだけでなく SafariのWeb上でも 動作します 次に その実装を見てみましょう まずプラットフォームが提供する 強力なフィッシング対策が Appで機能するためには AppとWebサイト の間に強い関連性が必要です これは 「webcredentials」 関連付けタイプを使用して関連付け られたドメインを通じて行われます ここでは詳しくは触れませんが 数年前に公開された 「Introducing Password AutoFill for Apps」 のビデオを見れば詳しいことが 分かります 次にアカウントの作成 について説明します このコードは 実際にはかなり単純です これを細かく見ていきましょう createAccount関数 には次の3つの入力が必要です サーバから取得した1回限りの チャレンジ アカウントの ユーザー名とユーザーID ユーザーIDは通常バックエンドの アカウントの識別子です まずリクエストオブジェクトを 作成するためのリクエスト プロバイダが必要です relyingPartyIdentifier はWebAuthn の設定によって異なりますが 通常はドメイン名です このプロバイダを使用して registrationRequestを 作成し要求を許可する コントローラに送信します 最後に許可コントローラ にデリゲートと presentationContextProvider を設定し要求を開始します これにより先ほどのシートが ポップアップ表示され 認証情報を作成するように 求められます トランザクションが終了すると 新しい認証情報の詳細を含む デリゲートコールバック を受信します さてサインインは非常に よく似ています いくつか変更が必要な点が あるだけです registrationRequest を作成する代わりに サインイン時に使用される WebAuthn用語である assertionRequest を作成します assertionRequest に必要なのはチャレンジだけです 変更する必要があるのは これだけです 許可コントローラに対する このパラメーターが 配列であることを 強調したいと思います Appがサポートするさまざまな 認証メカニズム の リクエストのリストを パスワードや Appleでサインインを 含めてここに送信できます 以前のシートには 現在利用可能な 認証情報が入力されます 唯一の注意点は パブリックキー登録要求と 非登録オプションを混在させ てはいけないということです 最後に 認証が完了したら デリゲートオブジェクトへの 呼び出しについて説明します 認証情報は 指定された許可オブジェクトの プロパティです ユーザーが新しいプラットフォーム 認証情報を登録した場合は プラットフォーム認証情報の 登録を受け取ります 既存のプラットフォーム認証情報を 使用してサインインした場合は プラットフォーム認証の アサーションを受け取ります また、あなたがサポートしている 他の何かを使って サインインする場合は ここでもそれを処理できます いずれにしてもWebの場合と 同じように認証情報オブジェクト から必要なプロパティを読み取り これらの値をサーバに 送信して検証し 操作を完了する必要があります これがその仕組みです さてもう少し詳しく お話ししたいと思います パスワードからの移行には 時間がかかるため 詳細を正確に理解することが 重要です macOS Montereyと iOS 15では iCloudキーチェーンの パスキーがテクノロジープレビュー としてリリースされ デフォルトでオフになっています iOSでは設定Appの 開発者設定セクションに 新しいスイッチがあります これをオンにするとこれらの 同期されたキーをAppと Webの両方で 使用できるようになります macOSではこのスイッチは SafariのDevelopメニューにあります まずSafariの Advanced settingsで Developメニューを オンにする必要があります この設定は Safariの環境設定の 詳細パネルの下部にあります その後 開発メニューに 同期プラットフォーム認証を 有効にするオプションがあります テスト時には 必ずこの機能をオンにしてください macOS Montereyと iOS 15では これらのパスキーはテスト用であり 本番アカウント用ではありません 今回のプレビューで 強調したいのは 認証技術であり iCloudキーチェーンで サポートされる WebAuthnの実装です パスワードから業界全体への 移行には 思慮深く一貫して適用された デザインパターンが必要であり それはこのプレビューには 含まれていません 最後に これはプレビューであるため オフにした時に正常に動作する ことを確認しました プラットフォーム 登録要求はエラーを返し スイッチがオフの場合は 他の認証要求タイプ と混在している場合でも プラットフォームアサーション 要求はサイレントに無視されます ここでは 次のステップについて説明します パブリックキーベースの フィッシング対策の認証情報は アカウント認証の次の開拓分野です 開発者向けドキュメントと このビデオからリンク されているサンプルコード を参照してください まだWebAuthn を持っていない場合は サーバでWebAuthn実装を 起動すれば WebAuthnベースの認証情報の試用を 開始できるようになります さて 私のお気に入りの部分で iCloudキーチェーンの パスキーのテクノロジプレビューを 試してWebサイトや Appの既存のワークフローに どのように適合するかを 確認してください 試したら ぜひ開発者フォーラムと フィードバックアシスタントで 感想を聞かせてください ご連絡をお待ちしております すでに述べたように これはパスワードを置き換 えるための複数年にわたる 取り組みの最初のステップであり 皆さんの意見はとても大事です ご覧いただいてありがとうございます ♪