Live data from Hacker News

A well-known URL for changing passwords

github.com

21–30 of 179 posts

Re: A well-known URL for changing passwords

#21
post #10

That looks like a good idea, but why not go one step further? Provide a common API interface for password changes. Think about it: If you assume your pw manager database is compromised - what do you do? Go to a hundred webpages and change your password? probably not. Your PW Manager can't provide a feature to do it for you. But it could if there was such an API.

I naively assumed that this was the point, but when I read the spec you're right: it's just about hitting the well-known URL and redirecting the browser to the actual change-password URL. Does anybody know why, from the site maintainer perspective, why would I bother to implement this?

Re: A well-known URL for changing passwords

#23
I see the argument for simplicity, but I think it would be much more impactful to have a well-known URL for automated password changes.

It's common to see advice to "change all your passwords" following incidents like Heartbleed or Cloudbleed or after having a personal computer hacked.[0]

This advice is useless -- it's way too time consuming, and also comes too late. If you need to change all your passwords now, you actually needed to do it six months ago.

A well-known URL that specified password requirements and an endpoint to hit with username, old and new passwords would let password managers reliably and routinely update passwords instead. To the extent "change all your passwords" is ever good advice, it would become advice you could follow automatically instead of never.

[0] Example of the form: https://securitywatch.pcmag.com/hacking/322494-heartbleed-fa...

Re: A well-known URL for changing passwords

#24

Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. " https://evilsite/changepasswords" and wait for Password Managers to be updated. The fact that the spec says nothing about where a user can be redirected, and which domains/sub-domains are within scope for which change password requests seems like an oversight. For example if my…

Well, since password managers already tie a password to a specific domain, presumably they would use the same logic for determining the scope of the well-known URL. I do agree that the spec could probably benefit from clarifying this, but I bet "the same domain as one of the recorded login URLs" is sufficient. (And the password manager would never even know to check evil.example.com if you hadn't ever put that password into that subdomain).

Re: A well-known URL for changing passwords

#25

Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. " https://evilsite/changepasswords" and wait for Password Managers to be updated. The fact that the spec says nothing about where a user can be redirected, and which domains/sub-domains are within scope for which change password requests seems like an oversight. For example if my…

Well, since password managers already tie a password to a specific domain, presumably they would use the same logic for determining the scope of the well-known URL. I do agree that the spec could probably benefit from clarifying this, but I bet "the same domain as one of the recorded login URLs" is sufficient. (And the password manager would never even know to check evil.example.com if you hadn't ever put that passwo…

> but I bet "the same domain as one of the recorded login URLs" is sufficient.

What is that a quote from? I cannot find it in the spec here:

https://wicg.github.io/change-password-url/index.html

Re: A well-known URL for changing passwords

#26

Earlier quoted context omitted.

I think LetsEncrypt uses it, no?

Yes, also OpenID Connect.

sadly only for discovery. but it would be great if oauth/openid connect would actually use .well-known/authorize, etc. instead each provider has it's own sauce.

Re: A well-known URL for changing passwords

#27
post #23

I see the argument for simplicity, but I think it would be much more impactful to have a well-known URL for automated password changes. It's common to see advice to "change all your passwords" following incidents like Heartbleed or Cloudbleed or after having a personal computer hacked.[0] This advice is useless -- it's way too time consuming, and also comes too late. If you need to change all your passwords now, you…

There's room for both ideas.

This one has the benefit of being stupid simple to implement and maintain. In 10 minutes I can throw this together for all of our login stuff.

But a fully automated password changing system/API? That's not exactly as "maintenance free". Now you are maintaining a full API separate from your normal routines, and it's in an area that I always advocate for simplicity since subtle mistakes can mean compromised accounts. And the "fully automated" API would also have to work with "multi-factor" systems, which alone make everything more complicated to cover all the different ways it's done.

Don't let the possibility of a better solution kill the benefits of this simpler one.

Re: A well-known URL for changing passwords

#28
Here is the actual spec: https://wicg.github.io/change-password-url/index.html

Presumably this is only for accounts you are already logged into and want to change the password of, since change password forms usually aren't accessible unless you are already logged in.

However, the same domain may involve multiple account types. AWS and other popular websites have multiple types of accounts, different login methods, and different change-password forms, on the same domain. If all this URL does is redirect to one single page per domain, it won't work for cases of more than one type of login.

Also, it seems that password reset is a lot more common than just changing a password, so maybe this spec could be extended to that form, too?

Re: A well-known URL for changing passwords

#29

Earlier quoted context omitted.

Well, since password managers already tie a password to a specific domain, presumably they would use the same logic for determining the scope of the well-known URL. I do agree that the spec could probably benefit from clarifying this, but I bet "the same domain as one of the recorded login URLs" is sufficient. (And the password manager would never even know to check evil.example.com if you hadn't ever put that passwo…

> but I bet "the same domain as one of the recorded login URLs" is sufficient. What is that a quote from? I cannot find it in the spec here: https://wicg.github.io/change-password-url/index.html

Sorry, intended as a hypothetical suggestion, not a quote.

Re: A well-known URL for changing passwords

#30

Earlier quoted context omitted.

> but I bet "the same domain as one of the recorded login URLs" is sufficient. What is that a quote from? I cannot find it in the spec here: https://wicg.github.io/change-password-url/index.html

Sorry, intended as a hypothetical suggestion, not a quote.

Oh understood. Yeah that suggestion would fix my concerns almost wholesale. They just need to think about scoping it to e.g. domain, subdomain, etc.
Post reply on HN