Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A well-known URL for changing passwords

github.com

Post reply on HN
Print view View original

71–80 of 179 posts

Re: A well-known URL for changing passwords

#71

Post by tzs »

Someone1234 wrote: post #20
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 has been tried before and failed (REST XML Schema, for one example). Site operators just don't want to maintain two complete copies of their password change infrastructure (one for people, one for programmable interaction). The current system puts more work onto the password managers themselves, but realistically even if there was a generic API, the sites themselves aren't generic, each one requires a different se…

> Site operators just don't want to maintain two complete copies of their password change infrastructure (one for people, one for programmable interaction)

Couldn't the former use the latter?

Re: A well-known URL for changing passwords

#72

Post by WorldMaker »

buster wrote: post #64
WorldMaker wrote: post #54

Earlier quoted context omitted.

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…

I'm saying that the closest thing we have to a well-adopted standard for securing a "simple PUT request" for something as security critical as a password is called OAuth.

You need CSRF tokens to avoid replay attacks. You need some way for an app to Authorize: that they have permission to update someone's password. That's probably some sort of application whitelist. That application whitelist probably needs a permissions flow for a user to agree that Password Manager Brand X is indeed their password manager application of choice. Do we have a standard for such permission flows and app-specific bearer tokens? Oh look, it's OAuth that says "hi".

Re: A well-known URL for changing passwords

#73

Post by geofft »

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?

It doesn't support things like SSO / federated authentication, multiple password fields for 2FA, multiple username fields for realm/domain and individual account, etc.

The web already has a perfectly good solution for arbitrary forms, and has had it for decades. Just use that.

Re: A well-known URL for changing passwords

#75

Post by geofft »

Someone1234 wrote: post #44
xena wrote: post #38

Earlier quoted context omitted.

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.

You stated you were unsure what it was. The link clarifies that.

And it is a specified standard: the link is the specification. It's not a standard developed by a multi-stakeholder standards organization, but there are other kinds of standards, too.

Re: A well-known URL for changing passwords

#76

Post by tzs »

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?

GnuPG can use /.well-known/openpgpkey since 2.1.12, and it is used by default since 2.1.23, when you do --lookup-key.

E.g.,

  $ gpg --lookup-key foo@example.org
will include among the places searched /.well-known/openpgpkey/hu/?l=foo at example.org It also looks at /.well-known/openpgpkey/policy.

Toss in "-auto-key-locate=clear,wkd,nodefault" to force it to look there for the key even if it already has a key for that email address.

Re: A well-known URL for changing passwords

#77

Post by madamelic »

Someone1234 wrote: post #20
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 has been tried before and failed (REST XML Schema, for one example). Site operators just don't want to maintain two complete copies of their password change infrastructure (one for people, one for programmable interaction). The current system puts more work onto the password managers themselves, but realistically even if there was a generic API, the sites themselves aren't generic, each one requires a different se…

>Site operators just don't want to maintain two complete copies of their password change infrastructure (one for people, one for programmable interaction).

Seems like the issue isn't the idea, it's the way they're implementing it.

Shouldn't it be ui(api(pwd changing code)), not ui(pwd changing code) + api(pwd changing code)?

> even if there was a generic API, the sites themselves aren't generic, each one requires a different series of steps with unique error messages

Again this sounds like an implementation issue, not an idea issue.

People can use all of kinds of weird status codes if they like as long as they implement 200, 401 and 500. Those three cover the bases.

And I don't think the proposal covers any site-specific options and could standardize on key naming (`email`, `password`, `username`, etc) Password managers already keep this info and more, I think LastPass will even store your credit cards and has profiles so you can swap between business, personal and other info.

Re: A well-known URL for changing passwords

#78

Post by ghostly_s »

From the spec:

> Servers must not locate the actual change password page at the change password url, per RFC5785 §1.1 Appropriate Use of Well-Known URIs.

I scanned the RFC but can't fine the prohibition against this. Curious, why does it matter? Just because .well-known URLs are not meant to be exposed to the user?

Re: A well-known URL for changing passwords

#80

Post by Piskvorrr »

Tharkun wrote: post #53
gwbas1c wrote: 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.

"Yeah, let's login via FB! Oh wait, a few report-user requests, and now you cannot get anywhere, easy DoS." Social network and SSO are as opposite as you can get.
Post reply on HN