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.
A well-known URL for changing passwords
21–30 of 179 posts
Re: A well-known URL for changing passwords
#22[removed]
Re: A well-known URL for changing passwords
#23It'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
#24Seems 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…
Re: A well-known URL for changing passwords
#25Seems 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…
What is that a quote from? I cannot find it in the spec here:
Re: A well-known URL for changing passwords
#26Re: A well-known URL for changing passwords
#27I 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…
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
#28Presumably 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
#29Earlier 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
Re: A well-known URL for changing passwords
#30Earlier 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.