Live data from Hacker News

A well-known URL for changing passwords

github.com

41–50 of 179 posts

Re: A well-known URL for changing passwords

#41
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.

On that note though, if we start using standard APIs for this sort of thing, I question whether we should just go farther and "solve" the problem. Ie, as a dumb example, why should I expect them to implement an API for my password manager, and instead not simply allow oauth where my pass manager becomes my token provider? Doesn't that fake example solve both problems, while also getting rid of bizarre password churn?…

That's effectively what U2F provides. You can "nop" the password by using a bad password that you can trivially remember, and then your U2F token is, effectively, your only authentication.

I don't know what features U2F tokens support, but if they can be password protected I don't see why U2F being the only auth factor would be bad. You could even have the token itself attest to being password protected so you could require that of users before allowing them to disable non-U2F passwords.

Re: A well-known URL for changing passwords

#42

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, an…

Usually the place where you realize you forgot your password is the login form. So the 'standard' link/button/whatever below/next to/in proximity of the login form works quite well for this.

Since the spec is intended for password managers and other user agents, it makes sense to have a standard location to access such functionality.

Also the page could be anything (i.e. doesn't have to be a redirect) so theoretically AWS could set up an account chooser that has links to all the appropriate places for your accounts

Re: A well-known URL for changing passwords

#43
post #40

ooh can we also get /.well-known/delete-account ?? seriously though, I would love this for all those sites that bury it as far as possible...

This would be great, but like you said, the sites you would really want to use this for would likely never implement it. Unless it were a requirement of something like GDPR..

Re: A well-known URL for changing passwords

#44
post #38

Earlier quoted context omitted.

The one that Apple's browsers request on every domain isn't even in the list: /.well-known/apple-app-site-association That's the only .well-known request we have in our logs from the last year or more. Seems to be looking for an app associated with our site. Aside from that, I don't know anyone or anything else using .well-known. Seems to be an Apple thing.

Found documentation on it for you: https://developer.apple.com/library/archive/documentation/Ge...

The discussion was about specs/standards for .Well-Known. I pointed out that Apple's isn't in the list.

In that context I don't follow why you think linking to Apple's development guide helps clarify anything? It still isn't a specified standard, and still isn't on the list of them.

Re: A well-known URL for changing passwords

#45

They say that iCloud Keychain on iOS 12 and Safari 12 have implemented this feature. And sure enough, https://www.icloud.com/.well-known/change-password Looking through the referenced RFC, there's a whole raft of "well known" urls that are registered https://www.iana.org/assignments/well-known-uris/well-known-... How widely adopted are these?

Yes

Re: A well-known URL for changing passwords

#46
post #33

Earlier quoted context omitted.

I don't understand your concern. If the attacker controls ` https://example.com/.well-known/change-password` wouldn't they also control ` https://example.com/my_profile/settings` ? Why bother redirecting the user to a third party site when you can just inject some password-logging JS into the _legitimate_ change password form?

If an attacker controls a subdomain and can trick a user into visiting it (e.g. evil.example.com), the cookies may be out of scope, but the password manager may (or may not) treat the subdomain as part of the domain in terms of .well-known/change-password requests, allowing a subdomain to redirect the password manager and potentially stealing credentials. It is undefined behaviour. The spec is under-defined. That's m…

I assume the password manager is supposed to prepend the host of the login form or whatever host is configured in the password manager.

So if I save example.com in my password manager, it will access example.com/.well-known/change-password no matter which urls I later visit that might be on subdomains of that original page.

If I already configured evil.example.com in my password manager, it's game over anyway before anything relevant to this spec even happens.

Re: A well-known URL for changing passwords

#47

They say that iCloud Keychain on iOS 12 and Safari 12 have implemented this feature. And sure enough, https://www.icloud.com/.well-known/change-password Looking through the referenced RFC, there's a whole raft of "well known" urls that are registered https://www.iana.org/assignments/well-known-uris/well-known-... How widely adopted are these?

As a site owner, how many of those should you handle?

Already do special handling of acme-challenge for Let's Encrypt/ACME but that's a given.

Re: A well-known URL for changing passwords

#48
The real problem is that every single site needs its own separate password.

(Even worse are products and services where you need a separate password for different features.)

The better way to solve this is to push for better account portability. We already (kind-of) have this with websites that let you sign in with your Google or Facebook ID. (Unfortunately, these systems still have privacy problems because they share your email, or the web site fails if you don't want to share your email.)

Re: A well-known URL for changing passwords

#49

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, an…

Where it links would be up to the website. The password manager doesn't know if you are already logged in or not, just that the user requested an intent to change their password at example.com. The password manager should just open the URL in the user's default browser. Then it's up to the website itself to redirect to a login flow if need be (they don't have a logged in cookie on that browser), including the password reset flow if necessary.

If a website has more than one account type that the user might want to change the password for, it could add some sort of flow to ask which account was meant. If the user has more than one account at the website, that becomes up to the user to make sure they signed into the right one that they wanted to password change. If the website is aware the user may have more than one account (such as Google's account switcher), they could present the options directly then.

It seems easy enough to do the right thing in most cases, given how simple this proposal is.

Re: A well-known URL for changing passwords

#50
post #48

The real problem is that every single site needs its own separate password. (Even worse are products and services where you need a separate password for different features.) The better way to solve this is to push for better account portability. We already (kind-of) have this with websites that let you sign in with your Google or Facebook ID. (Unfortunately, these systems still have privacy problems because they shar…

https://www.grc.com/sqrl/sqrl.htm

Though I think he will need a more convincing marketing site if he intends for people to try it out.

Post reply on HN