Live data from Hacker News

A well-known URL for changing passwords

github.com

51–60 of 179 posts

Re: A well-known URL for changing passwords

#51
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…

That is not a problem at all. Whenever you have a centralized oauth service, there will be a possibility to track its user. I don't see a way how any company might guarantee that it doesn't track me so I'd believe it.

Therefore I'd prefer to have an alternative to oauth with old school account creation on each and every website with separate login/password pair.

Re: A well-known URL for changing passwords

#52
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…

We really should have public keys that we can give away to these sites, and then there should be a challenge/response phase that our private keys (stored safely!) are used to sign the challenge.

Of course that would mean you carrying around a physical token that needed to talk to your browser(s), phone(s) etc.

Passwords should GTFO tbh.

Re: A well-known URL for changing passwords

#53
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…

This nonsense comes up every time anything related to a password is mentioned. Google & Facebook login are evil. And people end up picking stupid Google & Facebook passwords anyway.

Every single site needing its own password is a feature, not a bug. Educate people about password managers instead.

Re: A well-known URL for changing passwords

#54
post #39

Earlier quoted context omitted.

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?…

I think you answer yourself already. You expect this: > simply allow oauth where my pass manager becomes my token provider to be a simpler implementation then "PUT https://blabla.com/change-password" or whatever a password change request would look like?

That "simpler implementation" of PUT https://example.com/magic-api/change-password has all sorts of security concerns you aren't considering. How do you stop "rogue" password managers from using it? How do you stop replay and man-in-the-middle attacks?

The other poster is correct that immediately people would jump to using OAuth as one solution to manage which password manager apps can access that change password flow somewhat securely. At which, yes, why not just invert the OAuth flow and find better ways to make the Password Manager the provider rather than https://example.com and maybe eliminate the password entirely from the equation while we are at it.

Re: A well-known URL for changing passwords

#55
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 still don't see your point.

If your password manager autofills your credentials for `example.com` when you visit `evil.example.com` then the owner of `evil.example.com` already has an easy way to steal your credentials regardless of whether or not this spec is implemented.

Re: A well-known URL for changing passwords

#56

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…

I wonder if URLs like /.well-known/login and /.well-known/logout would be a good idea, and should belong to a similar spec. Maybe even /.well-known/register, too.

Re: A well-known URL for changing passwords

#57
post #17
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.

Dashlane has that feature [0], though not for all sites of course. I haven't tried it out but I don't see why they couldn't have it working for say the 1000 most popular sites, which would cover at least half of my needs. [0] https://support.dashlane.com/hc/en-us/articles/202699281-How...

LastPass had a similar feature when I used it. It often broke and was overall unreliable, as all scrapers are wont to be. Worse - when it failed, you couldn't be sure at what point of the process it had done so, leaving your accounts potentially inaccessible.

Re: A well-known URL for changing passwords

#58

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?

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.

WebFinger, a key underlying tech of the Fediverse and used for bootstrapping OpenID Connect, ActivityPub, and many other standards uses .well-known.

https://webfinger.net/

Re: A well-known URL for changing passwords

#59
post #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?

Because it takes very little effort and adds convenience for your users, that's why.

The alternative of doing a full API takes much more effort and therefore has little chance of adoption.

Post reply on HN