Add mechanism to signal from UA to server whether a newly created password was generated

[mweissbacher]

To address password reuse, this proposal suggests adding functionality to allow a server to signal to a UA that it wants to be notified if a random password was generated. In turn, the UA should have a mechanism to let the server know whether the password was in fact generated. Web servers could use this information either to nudge clients towards generated passwords or at least use it as risk signal, e.g., by requiring a second factor or treating an account as higher risk of takeover.

Motivation

Much work has been put into how to generate passwords properly and what a strong password is. Also, UAs and password managers offer functionality to generate unique passwords. However, servers do not know whether a password is unique or is merely a strong password that is reused across multiple sites. This proposal suggests to let the server know whether a strong random password was uniquely generated, and to do so this proposal utilizes already established mechanisms.

Background

Password reuse is hard to detect on the server side. Much work has been put into databases or Private Set Intersection to disallow known-leaked passwords. However, passwords require being breached first to be in a database which limits the approach and only helps after the fact. With this proposal, servers are able to address password reuse before and independently of a breach. This approach also avoids centralization into a single source of hashed passwords.

But why improve passwords?

Much work has been put into replacing passwords with hardware tokens, single sign on etc. However, the reality is that passwords are still used for authentication daily and are likely to remain in use for the forseeable future. This proposal aims to improve the state of the art of passwords in a tangible manner, rather than aim for moonshot properties that are unlikely to succeed.

Suggested Implementation

To highlight the use case - one way to implement this approach would be by extending the WhatWG proposal for passwordrules content attribute. The passwordrules proposal provides specifications of what syntax a password should meet, but is missing an option to require generation.

We propose to extend the required property by adding generated and generated-prefix attributes. If the password is generated by the UA's password manager or an extension and not modified by the user, the UA should add an element to the submitted form to inform the server. The purpose of the prefix attribute is to prevent possible name collisions but also to guarantee the UA is interpreting the functionality correctly. The prefix is generated by the server and should be random at least in part. A known part can prevent collisions with other elements, a random part to verify intent of the UA. The verification procedure is similar to WebSocket session initialization. The content of the duplicated field is a base64 encoded value of the name of the duplicated pw field (prefix plus name of pw field). The password may not be part of the duplicated form, it should only be transferred once.

As an example, consider the following password field using the passwordrules proposal with additional attributes generated and generated-prefix.

<input type="password" minlength="8" passwordrules="required: generated; upper; required: lower; required: digit; generated-prefix:gen-AAAAA-;">

Assuming the UA generates a password, and the form contains a password field named pw, on form submission the UA duplicates the password field. The names of duplicated password fields prepended the generated-prefix. In this example, two password fields are submittted. pw with value set to the new password, and gen-AAAAA-pw with value of base64 of "gen-AAAAA-pw" ("Z2VuLUFBQUFBLXB3"). This change leads to minimal additional data transfer and server-side functionality does not require to be changed to remain compatible. The server can tell that the password has been generated by a password manager based on the duplicated password fields. The server must verify whether the name of the duplicated field was correctly encoded and set as value.

If the password is modified or the password generator was not used, no form changes should be performed. Overall, we believe this to be a minor change in the UA, relying on already existing UA or password manager functionality.

Web servers could check whether the UA supports this header based on their UA version. Thus, a web service could warn the user when passwords are not generated by the UA. Advantages of this approach are that it can be implemented in a UA without affecting services, and services can gradually opt into using it as it becomes available in browsers.

Security model

For this approach, we explicitly trust the UA. In any case, UAs cannot be part of the threat model, as they always have access to passwords. Note that a user could bypass this approach, e.g., by modifying the form. However, it is generally accepted that user-security is bypassable by the user itself. Sophisticated users who tamper web forms might also understand the drawbacks of password reuse. This system would still be an effective measure to nudge the majority of users who are not aware of password reuse dangers towards a novel password.

Caveats

One drawback is that users who choose to pick a password themselves which is novel could be wrongly nudged to not reuse a password. However, it has been shown that humans generally pick bad passwords, and password managers compute stronger passwords. We are unaware of security drawbacks this approach would introduce. Letting a service provider know a password is novel merely lets them know a password has less value to an adversary and is less likely to be part of a third party breach.

Browser extension integration

When generating a password, browser extensions would be required to implement this proposal to signal to a server a password was generated.

Participants

People that have contributed to this issue: Erik-Oliver Blass, Gerald Wodni

[mweissbacher]

CC passwordrules discussion participants: @annevk @zcorpan @tkent-google @rniwa @hober @othermaciej @mikewest @battre

[mweissbacher]

To update the proposal: Rather than extending required it would make more sense to introduce inform to exist alongside required and allowed. The proposal suggests to inform the server a password was generated rather than require generation. This naming makes things more clear.

Also tagging @dbates-wk as the original passwordrules author.