Microsoft to combat Chrome autofill fraud by adding more friction

In theory, you’re the only one who can log into your device and access your autofill details.  In practice, this is not always the case.

Users mindful of friends accessing their accounts sometimes opt-out of the autofill feature, but its absence is undoubtedly noticed when you have to remember numerous passwords.

Microsoft engineers have now addressed concerns expressed by users in a post on GitHub:

Users who want to quickly share their devices with family and friends have expressed concern over their accounts being accessed without their permission due to the behavior of autofill in the browser. For example, consider a user, UserA, who has their credential for social.example saved in the browser for ease of login. Even if UserA signs out of their social.example account before handing their device to UserB (a friend or family member) to borrow, autofill will still automatically inject UserA’s saved credential into the login form if UserB navigates to the social.example home page. This allows UserB to sign into UserA’s account with a single click. Additionally, UserB can trivially reveal the plaintext of the injected password.

The idea of a master password solution goes back over 10 years, however, Microsoft did not follow through with the idea as they were unsure “whether a master password feature that’s not backed by either per-credential or complete credential store encryption lures users into a false sense of security because local attackers are generally outside of the browser threat model.”

Fast forward to 2020, Microsoft has now proposed a solution that addresses these concerns.  “Based on user research/feedback”, the company suggests “an off by default, OS reauthentication hook in the Chromium autofill code path” is the solution.

Such reauthentication could involve re-entering an OS-level password, but may also encompass lower friction, biometric solutions on devices and operating systems that support them. Whether, and if so how, user agents choose to build UI around this reauthentication hook to ensure that their users can clearly understand the threat model and its limitations is beyond of the scope of this explainer.

Should the user opt-in for the reauthentication hook, Microsoft wants the user to have as much control over their UX as possible.  Here’s the proposal on GitHub:

This explainer proposes the addition of an off by default, OS reauthentication hook in the Chromium autofill code path. This will reuse the existing OS reauthentication logic used in Chromium’s password manager when previewing or exporting saved passwords and will add a content setting to configure how long a successful reauthentication should remain valid. By default, this content setting will be set to never require authentication, meaning that even if the build flag that controls this functionality is enabled, the reauthentication hook will not be functional until the user agent adjusts the default value (most likely by exposing UX for this to users).

Enabling this reauthentication hook and changing its off by default content setting will also enable the same behavior controlled by the Chromium fill-on-account-select feature flag. This decision was made to ensure that users are not prompted for authentication until they indicate they want to access their saved credentials.

Of course, the shared device scenario isn’t the only possible one; but Microsoft said that it “lays the foundation for future improvements.”

 We are open to exploring further investments in this space with other implementors to bring additional value to users.

Both Chrome and Firefox have already adopted Windows Hello authentication to authorise the display of saved passwords in Settings.  We can assume rather than asking us to remember another password, Microsoft likely intends to allow users to use Windows Hello biometric authentication to authorise the auto-filling of passwords for those who are concerned about shared devices.

Source: Windowslatest