RFC: Supporting Well-Known URL for Changing Passwords

phiw13 · 2021-10-12 07:04:15

/.well-know/change-password that would redirect to textpattern/?reset=1

spec text: https://w3c.github.io/webappsec-change-password-url/

supported in Safari for a quite a while and Chrome ( I think, based on this )

the unnamed CMS ticket

Ricky Mondello would like (Twitter) to see that more. This is mostly for the benefit of password managers.

(It might be possible to add this in the default .htaccess file ?)

Edit – corrected the name of the .well-known folder. the . (dot character) matters

Last edited by phiw13 (2021-10-13 00:45:55)

Bloke · 2021-10-12 08:04:24

I guess it’s unlikely that anyone will be using /well-known as a section so this is probably doable.

Adding to .htaccess is an option but that leaves other server technology out in the cold. Since we can’t rely on its presence in, say, Nginx or IIS, it means that links to /well-known will then fail for such users, leaving them unable to change their passwords without manual URL intervention. So I would suggest we bake it into core’s admin-side URL router.

gaekwad · 2021-10-12 15:22:47

Someone / something hits ./well-known/change-password and it bounces to textpattern/?reset=1, then the thing / person scrapes the page…presto, now they know the CMS. Ugh.

Maybe I’m overly paranoid, but I have sites where I don’t want to advertise the CMS used…or the web technologies used, for that matter, it’s all part of an attack surface that I want minimised.

So I’m not a total grouch, here’s the Nginx (untested) config snippet that should work:

    location = /.well-known/change-password {
         rewrite ".well-known/change-password" /textpattern/?reset=1;
     }

I respectfully counterpropose we add this as a docs entry as an optional thing for administrators to consider, not make it mandatory.

Edit: presentation.

Last edited by gaekwad (2021-10-12 15:42:05)

gaekwad · 2021-10-12 15:23:55

Bloke wrote #331774:

I guess it’s unlikely that anyone will be using /well-known as a section so this is probably doable.

To be pedantic, it’s .well-known, so it’s even less likely. I don’t know how Textpattern handles sections with dots / periods in, come to think on it…

Edit: on Textpattern 4.8.7, I cannot make a section with a leading . (e.g. .section-with-a-leading-dot), so it appears safe to assume that nearly zero people are doing that In Real Life.

Last edited by gaekwad (2021-10-12 15:40:59)

colak · 2021-10-12 17:18:42

Just a heads up that .well-known is used in the root of sites by some hosts.

gaekwad · 2021-10-12 17:53:34

colak wrote #331777:

Just a heads up that .well-known is used in the root of sites by some hosts.

rfc5785, come on down!

Bloke · 2021-10-12 20:37:16

Aha. dot well-known. Got it.

Intriguingly, change-password isn’t one of the set of well-known URIs mentioned – and it’s not in that RFC you linked either.

phiw13 · 2021-10-12 23:30:26

gaekwad wrote #331775:

Someone / something hits ./well-known/change-password and it bounces to textpattern/?reset=1, then the thing / person scrapes the page…presto, now they know the CMS. Ugh.

Respectfully, but this is a very weak argument. What’s preventing your scrapper | bot from checking for /textpattern anyway (in a list of known locations for CMS login panels) ?

And yes it is /.well-known/… sorry about that…

The LetsEncrypt automated installer uses it as well. IIRC.

… rfc5785, come on down!

… change-password isn’t one of the set of well-known URIs mentioned …

Both date from 2010. The proposal linked above is (much) more recent.

gaekwad · 2021-10-13 08:20:50

phiw13 wrote #331780:

Respectfully, but this is a very weak argument. What’s preventing your scrapper | bot from checking for /textpattern anyway (in a list of known locations for CMS login panels) ?

Fair. But I can guard against that with a web server rule (only permit certain hosts, authentication etc). I suppose the same could be said about hiding certain .well-known URLs, with that logic.

The LetsEncrypt automated installer uses it as well. IIRC.

It does, albeit in a temporary fashion as one of its methods to verify: the installer creates a file in that location, sends a message to the verification server to check for said file in so-and-so location, verification server confirms it exists, process continues.

(And since I’m already being an insufferable grump, it’s not just Let’s Encrypt! that does this: many ACME TLS setups use this route, especially the ones powered by certbot, which was an LE! property until they passed it to EFF stewardship.)

I’ve re-read my post above, and while I stand by it, the tone is not appropriate or helpful – so respectfully I will withdraw from further discussion about it and go along with the consensus.

phiw13: Please forgive any unintended terseness on my part.

phiw13 · 2021-10-14 02:45:40

gaekwad wrote #331781:

phiw13: Please forgive any unintended terseness on my part.

Oh, I did not detect or perceive any of that. I think… I was surprised about the “privacy” argument used, though as –and you know that I am sure— there are soo many small and not soo little ways to detect that Textpattern generated those pages.

My evil bot “that-friendly-sunday-afternoon-commie-visitor” will of course check everything irrespective of barriers and it will detect attempts at obfuscation (using sophisticated non-AI), it might even decide to take a second look… (evil thing it is!)

so yeah…

If you need the extra layer(s) of protection, you know better than me the myriad of ways to hide and protect things. A reason for possible inclusion of this feature in Textpattern Core is to make it easy for everyone.

lets encrypt.

Yeah I know about the ACME thing. Using LE was an easy shortcut using a .well-known example (pun… ?) to illustrate the case. And one that is now officially registered I noticed. change-password is only listed at Wikipedia so far (it might be included in a next round, the latest batch of registered URL date from 2019. Given how far those registration things move, it is not surprising that the feature discussed here is not yet included).

–~-

Anyway, what is the consensus: something worth of further investigation on GH?

phiw13 · 2021-10-28 02:40:29

I finally got around to fill a ticket on GitHub: Issue 1746

Textpattern CMS

Textpattern CMS support forum

#1 2021-10-12 07:04:15