w3c/webappsec-change-password-url

A Well-Known URL for Changing Passwords

A Well-Known URL for Changing Passwords

Table of Contents

• Proposal
• Frequently Asked Questions
  • Why not allow sites to override this location with an HTTP Link header or an HTML link element?
  • Why not serve a JSON resource with links to other account management functions?
  • What tools have implemented this feature?
  • What about servers whose HTTP response codes are unreliable?

Currently, if the user of a password manager would like to change their password on example.com, basically all the password manager can do is load example.com in a browser tab and hope the user can figure out how to update their password themselves.

The goal of this specification is to do the simplest possible thing to improve this situation, by defining the /.well-known/change-password well-known resource.

Proposal

example.com provides a /.well-known/change-password resource which redirects to their change password form, wherever it happens to already be.

Password managers check for the existence of /.well-known/change-password on https://example.com.

If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate there when the user indicates they'd like to change their password.

That's it, really. It's a pretty simple idea.

Frequently Asked Questions

Why not allow sites to override this location with an HTTP Link header or an HTML link element?

Implementation complexity. (This would require keeping site-specific state client-side, verifying & invalidating said state periodically, etc.)

Why not serve a JSON resource with links to other account management functions?

Specification complexity. If we determine we need other account management well-known resources in the future, we can specify them then.

What tools have implemented this feature?

• iCloud Keychain on iOS 12
• Safari 12
• 1Password (1Password 8 and 1Password for Chrome, Firefox, Edge and macOS Safari)
• Chrome 86
• Backdrop CMS, via the Well-known module.

What about servers whose HTTP response codes are unreliable?

Sometimes, HTTP servers are configured to respond 200 OK for resources that really aren't there. The Detecting the reliability of HTTP status codes draft attempts to address this problem.

webappsec-change-password-url's Issues

Add a parameter to specify a language version of the app

Some apps have different language versions. The client could specify what version should be returned to the user by adding an optional parameter like "lang" or "locale" containing the ISO 639-1 code.

Be explicit that this specification is about "changing a password", not "resetting a password"

I have been implementing this specification for Backdrop CMS via the Well-known module. After reading the specification I was unsure of how I should be handling an anonymous user arriving at http://example.org/.well-known/change-password. Indeed, initially I mistakenly implemented this by redirecting them to the reset password page. This mistake has been corrected, but I think it would be would be nice if the specification was more explicit on this point.

I think it would add clarity if the specification distinguished between changing a password verses resetting a password; and that the expected behaviour for anonymous users is that a website should invite a user to login before redirecting them to the change password page.

There is a reference to this subject in issue #4 by @craigfrancis, so this issue could be considered a duplicate of that one. However, I think it would be helpful to be explicit about the change vs reset terms in the specification.

Pathway to W3C adoption

Hi,

I'm working on implementing the change-password well known URL in Drupal core (see this issue).

A maintainer has asked about the pathway to W3C adoption. They are concerned about the potential of the /.well-known/change-password URL changing when formally adopted by the W3C, resulting in Drupal core having to support a legacy URL.

Are you able to advise on the pathway for this standard to be adopted by W3C (if at all)?

Thanks!

base origin has multiple apps

What if there are two apps, https://example.org/appA and https://example.org/appB each with their own login system with different sets of credentials?

Consider restricting the target of the redirect to be same-origin

See https://news.ycombinator.com/item?id=18618534

What about a link relation type?

It's a good idea to have a well-known URI for this, even though as I understand it, the typical use cases for well-known are cases when it's impossible to use embedded links for identifying a URI.
In this case, at least there's also the case for making the change-password-url discoverable from a resource (such as the home page of a user). I am wondering whether it wouldn't be useful to have a link relation type as well?

Update references & redirects to these documents

We can resolve this when WICG/wicg.github.io#8 and w3c/webappsec#569 land.

Clarify that redirects should be followed to resolve the Change Password URL

Today, we have this:

Clients must handle such redirects when requesting a change password url.

We should better clarify that resolving the Change Password URL may require following more than one redirect. For instance:

https://example.com/.well-known/change-password
may redirect to
https://www.example.com/.well-known/change-password
which may redirect to
https://www.example.com/actual-change-password-page

If a client only followed a single redirect, they’d be misled. This came up in issue #14.

Figure out how to get this to show up on wicg.github.io

Migrate to WebAppSec?

IIRC @mikewest invited us to move this to WebAppSec at TPAC last autumn. I think that's a fine idea. Any objections or concerns?

cc @rmondello @WICG/chairs

Clarify interpretation of RFC5785 §1.1

See https://news.ycombinator.com/item?id=18620373

Add informative text clarifying that servers may use complex logic to determine where to redirect to

As this is to change a password for an existing account, and not for a forgotten password.

If the user is not currently logged on, I assume it's acceptable to redirect to the login page first, then on successful login, redirect to the change password form?

What should clients do on OK status?

If "Servers must not locate the actual change password page at the change password url" I would expect servers redirect to the actual change password page as a response. However "Clients must handle ok status responses", how would such response should be handled? I guess it should be handled anyway as a valid response, would be great to clarify.

https://github.com/WICG/change-password-url/blob/5ea606f98f1282502fd9e4892d75b1135c5f9751/index.bs#L85

Register with IANA

Requested in protocol-registries/well-known-uris#12 and protocol-registries/well-known-uris#13.

Use RFC2119 to put constraints on actors doing $foo, not on things being $bar or having $baz

Only origins whose scheme is "https" may have a change password url.

This doesn't say what happens if origins who's scheme is "http" attempt to have one anyway.

I suggest deleting the "may" in the quoted sentence, and preferably also adding something that starts with "Clients must not [...]"

Broken reference for "Appropriate Use of Well-Known URIs"

In section 3:

Servers must not locate the actual change password page at the change password url, per RFC8615 §1.1 Appropriate Use of Well-Known URIs.

In PR #17, the reference was updated from the obsolete RFC 5785 to the current RFC 8615, leaving the section reference unchanged. However, 8615 does not contain a section 1.1, nor does it contain any section directly addressing the appropriate use of well-known URIs.

The best reference I can find in 8615 to support this spec prohibiting servers from locating the resource itself at the well-known URI is section 1, in which the RFC implies that well-known URIs are for metadata (only?): the penultimate paragraph includes "Future specifications that need to define a resource for such metadata [...]".

See also issue #9.

Who supports this?

Hi, WICG chairs are just going through the repos and checking status... I seem to recall Safari supports this feature (and twitter was using it, right?)? Did other browser vendors get behind it? If yes, should we consider moving it to the W3C or WHATWG?

Main branch should be named 'main'

Normative references to discontinued specs in A Well-Known URL for Changing Passwords

While crawling A Well-Known URL for Changing Passwords, the following normative referenced were detected as pointing to discontinued specifications:

• HTTP-SEMANTICS has been obsoleted by rfc9110

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

Punycode?

Origins have an ASCII domain, meaning that a host like example.إختبار will show up as example.xn-kgbechtv in the origin, and therefore in the change-password well-known URL. Is that what we'd like?

Malicious subdomain concern

This was raised on public-webappsec:

I am also concerning that draft is not considering 3rd level domains take over and how an attacker could advertise a password change URL to get a Beef kind of hooking of clients in a bot fashion.

Restrict redirection status codes to temporary ones

The spec accepts all redirect status codes, as listed in the fetch spec, including the permanent ones: 301 and 308.

Since 301 and 308 inform clients that the redirection is permanent, they might cache the URL found in the Location header, and stop calling the URL that triggered the redirection (here, the well-known URL)
I remember Firefox doing this at some point, and some proxies might also do this.

We can't be sure that website maintainers will not change the URL of their "change password" page. With permanent redirect status codes, some users might land on the old page, or on a 404.

This could be avoided by limiting the redirection status code to 302, 303, and 307.

Expand security considerations section

@terriko raised this concern on public-webappsec:

I do wonder if we should (non-normatively) mention the concern that having a well-known password change url could be used for nefarious purposes (e.g. sending a lot of emails, denial of service if there’s a rate limit on password changes, authentication attacks against security questions, etc.).

Adopt pr-preview

see https://github.com/tobie/pr-preview/blob/master/README.md

response-code-reliability checking for OK Status

The response-code-reliability proposal says: If response’s status is an ok status, reject p. Otherwise, resolve p.

Is this ideal? E.g. error codes like 502 Bad Gateway or 503 Service Unavailable don't positively indicate that /.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 behaves like expected.

Should we change the spec to look for /.well-known/resource-that-should-not-exist-whose-status-code-should-be-404 ?

Use GitHub Actions for deploying spec to the gh-pages branch

Consider ways of differentiating implementation and poor error pages

I've been experimenting with the .well-known/change-password route on a number of sites. On some, such as https://twitch.tv/, it's currently impossible to detect programatically that the route does not exist.

There are two reasons why this problem occurs:

• You see a redirect, as Twitch redirect users from their "naked" domain to the www subdomain.
• Twitch is a SPA, and doesn't seem to set status codes consistently. You see a 200 on the page you're redirected to, even though it's a 404.
  Requests occasionally go to the cache, and a 404 is correctly returned, so you may need to visit a number of times to observe this behaviour.

While in this example the server is setup incorrectly, for clients wishing to implement this spec, this is still a problem. It would be nice if servers were expected to exhibit additional behaviour (setting a header perhaps) so that more reliable detection could be done.

For my use case, I'm actually making CORS requests, so only know the status code and if we were redirected. It might not be possible for a solution to work for my use case - I certainly can't read headers - but am mentioning in case there is a CORS compatible option here.

Consider adding a bit more detail to the generation algorithm.

I'd suggest being a bit more pedantic about the URL generation algorithm. Perhaps something like:

1.  If |origin| is not a [=potentially trustworthy origin=], return failure.

2.  Assert: |origin| is a [=tuple origin=].

3.  Let |url| be a new [=URL=] with values set as follows:
    
    :   [=url/scheme=]
    ::  |origin|'s [=origin/scheme=]
    :   [=url/host=]
    ::  |origin|'s [=origin/host=]
    :   [=url/port=]
    ::  |origin|'s [=origin/port=]
    :   [=url/path=]
    ::  « "`.well-known`", "`change-password`" ».

4.  Return |url|.  

@annevk might have opinions about whether it's better to generate URLs this way or by feeding strings into the parser (if the latter, you'll need to serialize the origin before parsing it). This seems clearer to me?

Any follow-up drafts for fully automated password change?

See dani-garcia/vaultwarden#1691 (comment) .

Specifying navigations affected by .well-known/change-password

We noticed that the current draft does not specify which navigations should be affected by .well-known/change-password. I can think of several possibilities:

1. All navigations
2. All navigations in the main frame
3. Only navigations triggered by the browser (e.g. via a "Change password" button") - but not those triggered by a user-typed URL nor from links nor site-initiated navigations.

My intuition would go with 2 as this allows a website like https://passwords.google.com to just redirect to example.com/.well-known/change-password in the assumption that the user won't be greeted by a 404.

I can also see a reason for 3: In this case there would be less special casing for site-initiated navigations. Also browser extensions would probably have more control.

I don't see a lot of value in 1 (supporting the spec for iframes).

WDYT? @rmondello @hober