A well-known URL for changing passwords • Hacker News Board

Re: A well-known URL for changing passwords

#61

Post by toyg » Thu, Dec 06, 2018, 4:45 PM UTC

Ajedi32 wrote: post #33

Someone1234 wrote: post #14

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…

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?

Other attacks would have to be targeted, in most cases. Replacing a standard file under .well-known can be automated.

Re: A well-known URL for changing passwords

#62

Post by chias » Thu, Dec 06, 2018, 4:45 PM UTC

hannob wrote: 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.

It will take me about 10 minutes combined to set up the redirect in this proposal for all of my websites, with all of their varying auth paradigms.

Implementing some API spec that itself lets you change passwords for each one? No thank you, I have more important things to do.

Re: A well-known URL for changing passwords

#63

Post by dathinab » Thu, Dec 06, 2018, 4:45 PM UTC

nine_k wrote: post #56

peterwwillis wrote: post #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, 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.

Once the Web Authentication API becomes reliable usable this would make quite a lot of sense.

At last wrt. login and register for doing the "first" auth which is then stored in the authenticator, e.g. a username/password login).

Re: A well-known URL for changing passwords

#64

Post by buster » Thu, Dec 06, 2018, 4:53 PM UTC

WorldMaker wrote: post #54

buster wrote: post #39

Earlier quoted context omitted.

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

> How do you stop replay and man-in-the-middle attacks?

Replay what? Me setting my password over HTTPS? How?

The sample URL was deliberately just an example. It would surely need more thought but i'm pretty sure the "PUT ..." solution is simpler then throwing oAuth at the problem.

So you're confident that the same people who can't secure the simple PUT request are better suited to implement the custom oAuth solution you are talking about? And that will be secure? I'd bet against that.

Re: A well-known URL for changing passwords

#65

Post by marcosdumay » Thu, Dec 06, 2018, 4:59 PM UTC

nine_k wrote: post #56

peterwwillis wrote: post #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, 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.

Why not use simple HTTP authentication?

Re: A well-known URL for changing passwords

#66

Post by nathcd » Thu, Dec 06, 2018, 5:00 PM UTC

hannob wrote: 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.

For a polyfill of this functionality, check out pass-rotate: https://github.com/ddevault/pass-rotate

Re: A well-known URL for changing passwords

#67

Post by Immortalin » Thu, Dec 06, 2018, 5:03 PM UTC

gregmac wrote: post #7

This is a nice simple convenience feature, for sure [1]: > example.com provides a /.well-known/change-password resource which redirects to their change password form, wherever it happens to already be. > Password managers check for the existence of /.well-known/change-password on https://example.com . > If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate ther…

Here's an open source version of the common password rotation feature in most online password manager services: https://github.com/ddevault/pass-rotate

Re: A well-known URL for changing passwords

#68

Post by mikeleung » Thu, Dec 06, 2018, 5:06 PM UTC

isostatic wrote: post #4

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?

looks like the change was proposed by an apple WebKit developer:

https://github.com/hober

which would explain why apple has implemented it...

Re: A well-known URL for changing passwords

#69

Post by dec0dedab0de » Thu, Dec 06, 2018, 5:11 PM UTC

hannob wrote: 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.

And while we're at it just a common authentication API for http all together, with negotiable features like basic auth/form auth/session cookie/jwt/oauth/api token/csrf location/etc. Then we can make clients for every language to just log in to a website if you have the credentials. Web browsers could have a secure authentication widget that bypasses whatever the website has built in. It would be glorious

Re: A well-known URL for changing passwords

#70

Post by munk-a » Thu, Dec 06, 2018, 5:16 PM UTC

marcosdumay wrote: post #65

nine_k wrote: post #56

Earlier quoted context omitted.

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.

Why not use simple HTTP authentication?

A lot of site design requirements won't fit well with simple HTTP auth. If the company wants to display a password recovery link or display pricing information to potential customers it's incompatible with using HTTP auth without a lot of extra bells and whistles.

These are all relatively common business requirements.