摩擦を増やすことでChromeのオートフィル詐欺に対抗するMicrosoft

理論的には、デバイスにログインしてオートフィルの詳細にアクセスできるのはあなただけです。 実際には、これが常に当てはまるとは限りません。

友人が自分のアカウントにアクセスすることを意識しているユーザーは、オートフィル機能をオプトアウトすることがありますが、多数のパスワードを覚えておく必要がある場合は、オートフィル機能がないことに間違いなく気づきます。

マイクロソフトのエンジニアは、GitHubの投稿でユーザーが表明した懸念に対処しました。

家族や友人とデバイスをすばやく共有したいユーザーは、ブラウザの自動入力の動作により、許可なくアカウントにアクセスされることに懸念を表明しています。 たとえば、次の資格を持つユーザーUserAについて考えてみます。 social.example ログインを容易にするためにブラウザに保存されます。 UserAがサインアウトした場合でも social.example 借りるためにデバイスをUserB（友人または家族）に渡す前にアカウントを作成しても、UserBがに移動した場合、オートフィルはUserAの保存されたクレデンシャルをログインフォームに自動的に挿入します。 social.example ホームページ。 これにより、UserBはワンクリックでUserAのアカウントにサインインできます。 さらに、UserBは 自明に明らかにする 挿入されたパスワードのプレーンテキスト。

マスターパスワードソリューションのアイデアはさかのぼります 10年にわたってただし、Microsoftは、「クレデンシャルごとの暗号化または完全なクレデンシャルストアの暗号化に裏打ちされていないマスターパスワード機能が、ローカルの攻撃者は一般に ブラウザの脅威モデルに設立された地域オフィスに加えて、さらにローカルカスタマーサポートを提供できるようになります。」

2020年に向けて、マイクロソフトは 提案された これらの懸念に対処するソリューション。 「ユーザーの調査/フィードバックに基づく」と同社は、「デフォルトでは、ChromiumオートフィルコードパスのOS再認証フックをオフにする」ことが解決策であると提案しています。

このような再認証には、OSレベルのパスワードの再入力が含まれる場合がありますが、それらをサポートするデバイスおよびオペレーティングシステムでの摩擦の少ない生体認証ソリューションも含まれる場合があります。 ユーザーエージェントがこの再認証フックを中心にUIを構築して、ユーザーが脅威モデルを明確に理解できるようにするかどうか、またそうであれば、その制限はこの説明の範囲を超えています。

ユーザーが再認証フックをオプトインした場合、Microsoftは、ユーザーがUXを可能な限り制御できるようにしたいと考えています。 GitHubでの提案は次のとおりです。

この説明者は、ChromiumオートフィルコードパスにデフォルトでオフのOS再認証フックを追加することを提案します。 これにより、保存されたパスワードをプレビューまたはエクスポートするときにChromiumのパスワードマネージャーで使用される既存のOS再認証ロジックが再利用され、コンテンツ設定が追加されて、再認証の成功が​​有効である期間が構成されます。 デフォルトでは、このコンテンツ設定は認証を必要としないように設定されます。つまり、この機能を制御するビルドフラグが有効になっている場合でも、ユーザーエージェントがデフォルト値を調整するまで（ほとんどの場合、UXを公開することによって）再認証フックは機能しません。これをユーザーに）。

この再認証フックを有効にし、デフォルトのコンテンツ設定でオフに変更すると、 Chromiumfill-on-account-select機能フラグ。 この決定は、保存された資格情報にアクセスすることをユーザーが示すまで、ユーザーが認証を求められないようにするために行われました。

もちろん、可能なのは共有デバイスのシナリオだけではありません。 しかしマイクロソフトは、「将来の改善の基礎を築く」と述べた。

 ユーザーに付加価値をもたらすために、他の実装者とこの分野へのさらなる投資を模索することを歓迎します。

ChromeとFirefoxはどちらも、設定で保存されたパスワードの表示を承認するためにWindowsHello認証をすでに採用しています。 Microsoftは、別のパスワードを覚えておくように求めるのではなく、ユーザーがWindows Hello生体認証を使用して、共有デバイスを懸念しているユーザーのパスワードの自動入力を許可することを許可する予定です。

情報源： Windowslatest