Hacker News new | comments | show | ask | jobs | submit login
A well-known URL for changing passwords (github.com)
740 points by fanf2 3 days ago | hide | past | web | favorite | 166 comments





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 there when the user indicates they'd like to change their password.

It's not trying to enforce a particular password schema, it's not an API endpoint to automate changing passwords, and it is not trying to dictate site design or form layout.

It's also dirt simple to implement with practically zero cost.

Aside from Safari, it doesn't seem like any password managers have implemented this yet. It's also not in the IANA well-known URI registry [2] yet (even as draft), so that would probably at least allow it to get a bit more traction. Apparently they are working towards that [3].

[1] https://github.com/WICG/change-password-url/blob/gh-pages/ex...

[2] https://www.iana.org/assignments/well-known-uris/well-known-...

[3] https://twitter.com/rmondello/status/1042008520105779206


How about something like:

  /.well-known/delete-account
  /.well-known/request-user-data
This would also be nice as we wouldn't need things like https://justdelete.me

I can't imagine those taking off without legislation. Making it easier to change passwords is more or less in the interest of the companies who make web sites; making it easier to delete accounts or export all of your data, by comparison, is not.

Until users decide that the businesses interests of the companies that run the websites they use are less important than their own interests these features will never catch on. How about we stop using websites that fail to implement things that are good for us?

In fact, someone could write a browser plugin to put a screen between the user and the website that states "This website fails to implement .well-known link. Are you sure you want to continue?" like Chrome does for sites that have borked DNS. If a reasonably large number of people used that you'd see lots of sites implement this idea without needing regulations. I'd use that.


But then how would users get to Facebook? /s

You could have that plugin have a database of sites and also provide easy links for those sites that try to hide those functions.


Well, yes. I was solely looking from a user's perspective.

> making it easier to delete accounts or export all of your data, by comparison, is not.

Isn't this mandated to be present and accessible by the GDPR anyway?


Yes but present and accessible is a low bar. For most companies you have to email support to make this happen.

I can't imagine it either, but I wish we could try to establish things like these as having signalling value. Adding a redirect there is as trivial as it could possibly be, so if this could get established as "best practice", then there would be no excuse for companies not to support it.

Ultimately, not having a clear and easy policy for cancelling the service and deleting the account only happens when the company is malicious, and attempts to exploit the user. Having this visible plain as day is something I'd love.


My employer would have no problem with it.

We are a non profit, and don't run from user donations.


That's starting to cross over into SCIM - http://www.simplecloud.info/

It's a pretty cool spec and we use it in my day job (Okta) but it's not widely implemented. If a few major providers - like Google, Microsoft, Github, Wordpress, etc - implemented it, I think it'd explode.


Seems unlikely the Google, Microsoft, Facebook and their related entities would implement this though?

Yeah, no way these things will take off without legislation.

And regarding more legislation, no thanks.


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

The one nice thing about specifying a password change API would be that password managers could change passwords automatically, but I can definitely see the elegance in not attaching it to this specific spec (it could be achieved with a meta tag or similar).

off topic but I'm dying to know: why is the "American Society of Heating, Refrigeration, and Air-conditioning Engineers (ASHRAE)" in the "People" section of that IANA well-known URI list?

It's apparently because of an HTTP-based home automation protocol:

http://www.bacnet.org/

http://www.bacnet.org/Addenda/Add-135-2012am-ppr3-draft-17_c...


A lot of people in this thread seem to be unaware of the purpose of /.well-known/ .

You can read the memo about it here:

https://tools.ietf.org/html/rfc5785

Basically /.well-known/ is a place to check for common site meta data and you can suggest new urls that can be registered.

/.well-known/change-password

Has been accepted and added for the use case of pointing to where to change your password.

If you think this is insufficient then there is nothing stopping you from trying to put forward a more comprehensive proposal for say /.well-known/change-password-api that would contain all the meta data for whatever standardized scheme for informing multifactor/username/email api combinations you eventually come up with. Just because /.well-known/change-password exists it does not in any way limit what other suggestions can be made and implimented later (it only means that you need to use a different url).


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


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.


If every website has to "figure out" how to "do the right thing", do you just assume they'll all do the same thing in the same way? I think they'll all come up with different ways to solve the problems, which will result in a different user experience for each site. So users will have to do something different on every site when they want to change their password.

So it'll be the same as it is now, except that there's a button to start the process of doing the non-standard thing. I think a little bit of extra work on the standard could result in a more standard experience, and less work for the user.


They already do things the way they want. TFA doesn't change that. This kind of spec doesn't and shouldn't specify UX. It's simply "where do your users go to change passwords?" with a simple reply of "Here: $URL".

Right, the web has never figured out how to scale password UX. There are reasons websites don't intentionally use HTTP Basic/Digest Auth in 2018, beyond the basic implementation details that Basic/Digest aren't particularly secure. Most websites don't want a consistent user interface for password input. Login interfaces are important places to put branding, and include security theater to help users feel safe. The login page is the welcome mat of the web, and every site has a different idea of how it should be experienced, partly because that's a differentiator they want.

It's actually only relevant to UX. It's not useful as an API call. You can't feed it any data, and it doesn't provide anything but a single URL redirect. It will just become a big "Change Password" button on a password manager.

In order to change the password, you have to be logged in. So the website will have to redirect the user to a log-in form, passing along the change-password form URL when authentication succeeds. Then the user can put in the old password and new password, go through an optional MFA hokey-pokey, and get it changed.

If the intent is to speed up password changes, a few optional additions would be faster than the above. The spec could optionally allow (1) the account ID, (2) the user ID, (3) the old password, and (4) the new password. The response could be a challenge and consent request for the user, which the user could then affirm and submit.

The website could still dictate how this works, but the idea is that the password manager would pass along all relevant data in the initial request, eliminating the need for the user to enter it all manually, and eliminating extra page loads. But it requires no site-specific state on the client-side, because all requests would be exactly the same, to this generic URL. Whatever implements the spec URL on the server-side would perform the login and present the password reset challenge, pre-populated for the user.


I think you are confusing the applicable scope of what the proposal implements with something else you'd like to see implemented.

This is not even an API. It is merely a proposal that wherever your change-password form lives, people should be able to get to it via this specific path, too. Perhaps this whole thing is a terrible idea, but either way the problem they're trying to solve is different than the problem you're trying to solve.


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).



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.


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.


Also .well-known/change-profile and .well-known/post-comment and .well-known/add-to-cart.

change-profile is usually a single URL that operates on the current user. Which resource would post-comment and add-to-cart act on?

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


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/<some-sort-of-hash-looking-thing>?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.


<some-sort-of-hash-looking-thing> is ZBase32(SHA1(localPart)) and the standard is described here: https://wiki.gnupg.org/WKD

If one controls a domain, has HTTPS set up and uses PGP this is the easiest and most secure way to host a key (`gpg --list-keys --with-wkd $KEY` shows the hash value).

Enigmail, Mailpile, Mailvelope will automatically discover the key when composing an e-mail. ProtonMail is also working on integration of WKD with their web mail.




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/


I think LetsEncrypt uses it, no?

Yes, /.well-known/acme-challenge is used by LetsEncrypt.

Yes, also Keybase.

Yes, also OpenID Connect.

sadly only for discovery. but it would be great if oauth/openid connect would actually use .well-known/authorize, etc. instead each provider has it's own sauce.


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.


It really has no utility outside of Apple's app ecosystem, so why would you want it to become a standard?

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

https://github.com/hober

which would explain why apple has implemented it...


Yup, hi.

Regardless of what happens, thank you for trying to make the web a better place.

they are not well known

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.


As a site owner the main thing you should do about .well-known is be aware that it's special and so e.g. if you add a feature where users get a vanity page at www.example.com/username you shouldn't let them have the username .well-known

The leading dot is there both because that is already special in POSIX and because there's a good chance your validation whitelisting already forbids leading dots, just like newlines, slashes and other characters we can expect to cause mayhem. So this was a less dangerous choice than just well-known without the dot.


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.


This is the sort of scope creep that stops good things from happening. Sure, a full api for password changes sounds great. But why is that related to this project at all?

This project is something that will take approximately 5 minutes to implement, and probably not much more to design the "spec" in the first place. and as is, it does something worthwhile. A huge complex project in a related area isn't a replacement or an alternative, just a tangentially related thing that should have no bearing on this project. A .well-known url for password changes can provide real benefit for real people now, even though it doesn't do everything.


I'm very sympathetic to creating a password change API, but having a button that takes me straight there would certainly save my time and make me dread the process a lot less.

Next on that list would be "update my payment methods". Of course websites love complicating our lives by hiding it in multiple different places, so that may be of limited utility.


Just to be clear: I think this is a good project.

I also have taken 5 minutes to implement it in a system that I'm responsible for already.


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? Sure, it has the downside of "what happens when my password provider is compromised.." but that's always true, right?

An API for password managers feels like a solution to a problem we've created.

Don't get me wrong, I love the idea of reducing password churn. I'm just not sold on this specific method of handling it.


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.


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.


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


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".


You're clearly far too deep into the oAuth mindset:

  - You don't need "persmissin flows"
  - You don't need "to update *someone's password" (just your own!)
  - You don't need an "application whitelist" because HTTP doesn't know what an application is
All you need is to say "hey, here is my current password/hash. Update it to this one." on a secure channel (let's say, HTTPS). Alternatively "Hey, i am XYZ and this cookie tells you so. Update my password to XXX". I'm pretty sure there are a gazillion ways to securely make a request to some URL to update a password.

You're clearly not thinking of repercussions of having an open REST endpoint that anyone on the internet could just curl/postman/httpie to change someone's password.

Good password change forms have had CSRF tokens for decades now: https://en.wiktionary.org/wiki/CSRF_token

There are many known attacks whereby an attacker changes someone's password to control an account.

I don't care about OAuth at all. It's not an "OAuth mindset", it's a "I wouldn't trust a website at all in 2018 if it had an unsecure PUT endpoint to change my password" mindset.

HTTPS alone is not sufficiently secure. It's a start, but it is nowhere near enough on its own. SSL MITM attacks and Phishing are still problems today.

Requiring my current password isn't necessarily sufficient either: password cracking botnets exist. If the first sign that your password was cracked is that your password was changed to something only your attacker knows, that's not great. This is also where replay attacks come in. An attacker MITM or phishes this endpoint, and social engineers you into thinking you need to change your password, they get your old and new password together in one nice bundle.

Cookies aren't a sufficient answer for similar reasons. Again, take a look at cross-site request forgery issues and the history of replay attacks on password forms.

Application whitelists are a minimal security precaution to mitigate some botnets and phishing algorithms. HTTP does know what an application is, we often see application blacklisting done the hard way with User Agent strings and IP address ranges. Whitelisting is a more secure approach, but a lot harder to do securely (and why we have standards like OAuth; OAuth isn't the only answer, it's just the current easiest answer).


> that anyone on the internet could just curl/postman/httpie to change someone's password.

But that's my point. Keep it simple, let my password manager (be it on my mobile, laptop or whereever i want) change my password! Yes, i'd like that.

You don't even need that CSRF token, i don't know why. To prove your identity you'll only need to prove that you know you your password. That's possible, securely. See https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... and https://en.wikipedia.org/wiki/Zero-knowledge_password_proof

Why do you need an application whitelist?! The website i am visiting isn't whitelisting my browser, so why would it need to whitelist my password manager?


How lucky for you in 2018 that you don't seem to have any trouble with botnets trying to crack your passwords, hack your accounts, or even just break your accounts so that you cannot use them.

Exactly. Most password leaks seem to come from hacked websites and thus badly implemented security. And that's another point i was making: Keep it simple but secure, so that implementors have it simple and don't mess it up.

Can you point me to some source for botnets which crack passwords? I would be surprised. It's not feasible to brute-force a password over HTTP.


"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."

This scares me. Are you proposing it as something that is necessary, or something that is necessary as part of the parent poster's suggestion to use HTTPS + PUT? If the former, how does this scale across the multiple platforms I use? Ugh. Scary.


I'm saying it as a baseline of something necessary to use HTTPS PUT for automated password change solutions, to keep them even reasonably safe. I don't want every possible application on the internet with the ability to change my password, so of course I want a whitelist of applications that could ever possibly do that on my behalf. That seems like one clear, important requirement to me.

You are right, it doesn't scale well.

To me (and one of the posters above) it's just more proof that password infrastructure in general doesn't scale very well (because security attack surface scales proportionally), and that we really need a better solution. "Simple password change HTTP PUT REST API standard" is a security nightmare, and we should all be afraid of the mere idea of it. We should instead be looking to get rid of passwords altogether, for something that maybe does scale better. Such as the suggestion above that it would be better to try to sketch an API that asks our password/token managers to log us in, rather than the other way around, like an SSH Agent or an OAuth/OpenID provider or some better standard we could attempt to devise.


I'm not sure if I misunderstand what you are getting at but if you are talking about the .well-known/change-password thing that in this post, its just a well known _redirect_ to the regular change password page for that particular website, you cant PUT to it, it requires a human to navigate the page and fill out the password change form.

Unfortunately its not a well-known api endpoint.


I just meant, if we're expecting every site to implement an API to augment the password flow, why even use passwords? Why not get rid of them entirely, and have an API on every website that handles auth? OAuth was just an example of something that could (poorly?) serve as that.

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.


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 series of steps with unique error messages, etc. So while an API would save some work, password managers would still need bespoke steps per site.


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


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


Because it's a hard problem to solve, not technology-wise, but due to people. So it's best solved one step at a time. And a bait-and-switch model might just do it: First, overcome initial organizational inertia by a dead simple spec. It's so simple, an admin can implement it without asking anyone else for resources.

When it's done, the website is a good citizen to password managers, everyone is happy.

At some point, extend the spec, and display complying websites with a nice symbol. Then, after a while, display non-complying websites with a bad symbol. And a decade later, we're done ;)


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.

That's a good point. I guess they should keep the new and the old password until you've successfully logged in with the new one.

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.


Why not? Complexity.

I'd argue this reduces complexity by standardization. Having one system that is used among many sites allows easier verification of potential security pitfalls in that.

Well yeah, its less complex once you've persuaded everyone to adopt and implement it. I'm talking about the adopt and implement stage.

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

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

Don’t forget CORBA support! It’s a must have.

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 password manager saves a password for login.example.com, is a .well-known/Change-Password on evil.example.com, or example.com in scope? Who decides? Is it left to the password manager to figure out the security scope?


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 my issue, there has been no security pass of this at all. It is left up to each individual password manager to make this secure (or not).


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.


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.


Not necessarily. They can be on two different servers behind a reverse proxy, or the attacker can only write to static files or anything else.

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

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 password into that subdomain).

Changing your password for a google account seems to involve going to myaccount.google.com (which is not the domain your login is associated with) - so clearly this needs to support redirects to different subdomains.

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

Oh understood. Yeah that suggestion would fix my concerns almost wholesale. They just need to think about scoping it to e.g. domain, subdomain, etc.

This is so relevant. Just 10 mins ago, I got a short, casual, no-reply email from Teachable about an email & passwords breach.

If you're a startup and you're storing plaintext passwords out of expediency, realize you're doing a massive disservice to your customers. It seems they changed this in 2015, but didn't go back and fix it for their earliest adopters. Your early adopters make you what you are! Protect their data. And if you do mess up, don't send out a self-focused apology from a no-reply address.

We are writing to inform you of a suspected data breach involving accounts created between September 17, 2013 and November 21, 2015. We have reason to suspect that personal information related to accounts on Bitfountain (joined 2014-08-18) may have been compromised. This includes the email addresses and passwords associated with the school's Teachable (formerly Fedora) account.

As a precaution we are enforcing password resets...If you happen to use this password with any other service, we highly recommend updating your password there as well.

We apologize for the inconvenience, and thank you for your understanding in helping us keep Teachable safe.


Storing plaintext passwords is no faster than storing a cryptographically secure hash of the same password. We're not even talking lines of extra code, just a few extra characters actually hash the input.

It's not expediency, it's laziness bordering on criminal stupidity/negligence.


Well it should be faster than storing a cryptographically secure hash. If hashing the data is too fast, an attacker could just brute force all of the passwords.

That's why you should always use salt with your hash.

Unsalted, your password hash =

Hash({{Your Password}})

The attacker can brute force it from a dictionary or stepping through characters (possibly from another breach somewhere, or a silly password like boobies123).

Salted hashes are way more secure:

Hash({{Your Password}} + {{Secret}})

Now the attacker has to guess an extra secret phrase, which is often really long, that was fed into the hash function along with the user's password. And due to the beauty of one way hash functions both salted and unsalted hashes use the same amount of bytes in the DB... It's a no brainer.


It's not enough to just use a global salt.

You need to use a random salt for each user, which is stored in the DB.

You also need to use an algorithm that takes a lot of time - SHA1 and the rest are designed to be fast, on purpose. Use bcrypt or something.

(FWIW, PHP has the best batteries-included password functions i've seen in a language. `password_hash` etc just do the right thing. Copy what they do and you'll be ok)


The reason to use a salt is mostly that an attacker doesn't then have a precomputed library of hash values.

Say, if someone uses the password 'gwpmkq' and a site uses plain MD5, they store cc733aac12981561dfc4944dd34a595f in their database. Now, even a stupid attacker can google for a hash search engine, input the hash and get the password in seconds.

On the other hand, with salting the value to be hashed could be something like 'luser@fail.com:@362#^h6329hgtew:gwpmkq'. That won't be precomputed anywhere.

Of course it's also a good idea to either try to keep the salt secret or use a per-user random salt (which you store in the database). But when someone gets a full database dump, chances are they'll also get the salt.


The point of per-user salts is to avoid common passwords from revealing themselves, so that an attacker can't limit his brute-force attempts to just the users with shared passwords that will be easy to break.

The specific attack that per-user random salts are designed to prevent are pre-computed rainbow tables. Brute-forcing MD5 is nearly as fast as using rainbow tables, so the benefits are possibly dubious.

Who uses MD5 for hashing password anymore?

People one step above those who think storing plain-text passwords is okay.

I don't mean faster computationally I mean faster in terms of actually developing the product. In the scheme of even the simplest MVPs the additional developer time to hash an input twice is effectively zero.

Or maybe just ignorance?

Protecting a user's password is such a basic level of understanding I think ignorance falls under "criminal stupidity" for this one.

Ignorance of facts that any reasonable exploration of best practices in the area you are working in would reveal, in a commercial venture, is a product of laziness (or hubris) bordering on (or crossing into) negligence.

There's no excuse for plaintext passwords in 2019. Even the barest of frameworks provided mechanisms to hash and salt the damn things years before 2013.

Not salting/hashing at this point is more than a disservice, it's the equivalent of deliberately not washing your hands after wiping your ass, then going on to serve sandwiches.


I believe Unix passwords were salted and hashed in the 70's and those weren't typically for customer-facing accounts nor obviously for public internet-facing systems.

It boggles the mind that the 90s internet boom had to reinvent all the security wheels with such a great history to draw from -- then now that we have bothered to reinvent these wheels yet still decade or two back people are still delinquent in their use.


A salted presimised hash, of roughly the same sort we'd use today except that salt was only 12 bits (which seemed reasonable if your Unix systems have 500 users but not if your social network site has 500 million users) and the loop just runs the DES S-Boxes a bunch of times with no way to tune how many.

By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5 a configurable amount of times instead of DES some fixed number of times.


> By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5

That timing seems a bit optimistic to me, especially at large shops where the original crypt() implementation was necessary because you were using things like NIS, Radius, LDAP, etc. and had devices which didn't support MD-5 or better. I was still seeing that into the mid-to-late 2000s.


At some point it should become law.

Credentials are so common and the best practices around handling them have been around for what sounds like half a century. There's no protection for the average Joe who may reuse passwords and subsequently have it exposed in plain text or through an unsalted hash.

It's logical... In fact the GDPR makes some steps to enforce better handling of personal data and announcing beaches but I don't believe it enforces strong handling of passwords.


Just as an example once when changing the hashing for users on a relatively popular site.

Implemented new prefix + hash + salt system. On login, if old system was used, verify and re-hash with new password system. Notify users to login after 60 days of inactivity. After 90 days, clear all passwords that didn't have the new hashing system, forcing out of band change-password process. Worked out very well in practice.

It helps to have a plan to deprecate older hashing approaches to passwords.


I 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 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...


There's room for both ideas.

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.


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?


That section says:

   There are a number of possible ways that applications could use Well-
   known URIs.  However, in keeping with the Architecture of the World-
   Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
   for general information retrieval or establishment of large URI
   namespaces on the Web.  Rather, they are designed to facilitate
   discovery of information on a site when it isn't practical to use
   other mechanisms; for example, when discovering policy that needs to
   be evaluated before a resource is accessed, or when using multiple
   round-trips is judged detrimental to performance.
I am guessing they consider “general information retrieval” and “URI namespaces” to exclude it.

I did see that section, but don't see how it follows. Putting your PW reset page at this address would be using the URI spec for exactly it's intent, not “general information retrieval”. My read of this clause is just that they don't want you to start using .well-known as your primary namespace or cluttering the registrations with junk that's not broadly applicable.

Can someone clarify, is this actually for resetting a forgotten password? I don't quite follow.

example.com's change password functionality should be behind an authenticated page that requires a) the user be already logged in, and 2) the user's current password (for confirmation).

Whereas example.com's forgot/reset password functionality is usually a wide-open page anyone can reach to begin the process of password reset (more inline with what this spec seems to be describing).


Did you read the explainer?

> Currently, if the user of a password manager would like to change their password on example.com, basically all the password manager can do is load example.com in a browser tab and hope the user can figure out how to update their password themselves.

> The goal of this spec is to do the simplest possible thing to improve this situation.

It's an attempt to standardize the endpoint for changing a password. Which is kinda random for each website currently.


> Did you read the explainer?

I did. My confusion arose from it. Something is clear to you that is not to me :)


https://news.ycombinator.com/.well-known/change-password will just redirect to https://news.ycombinator.com/changepw. If the user isn't logged in, that page asks the user to log in.

Ah I see, and from the perspective of a password manager it would know what password to fill into the password field to get the user into the site. After that, once on the change password screen said manager would also take over generating a new password, yes?

I haven't read the proposal but it made me think of something like:

/.well-known/personal-access-token

To get an access token for API access to my own data. You know, for our right to be represented by a bot[1]

[1] https://continuations.com/post/172413445510/we-need-mandator...



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

Used by Safari for website password it identifies as used on multiple websites.

> If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate there when the user indicates they'd like to change their password.

The primary issue I see here is that there are a lot of websites that do 301 redirects from either non-www to www subdomain or non-https to https, would this not confuse the password managers in assuming there is a .well-known even though it’s just a benign redirect?


One thing I really wish when it comes to Firefox Containers if I create a container for Gmail and am logged into Google I want all the email links (mailto:) to open in that container. I know currently you can have all the sites with a specific URL to open in specific containers but I'm not sure if there is a way to open various protocols in separate containers.

I wish every site would just use emailed sign-in links instead of passwords. We wouldn't have to deal with all these password relative nonsenses - password managers, .well-knowns, password requirements, password resets, weak passwords, gazilion passwords in my head. Everything would be so much simpler

And then your email gets compromised and everything is immediately lost? No thanks

Everything is already lost if your email is compromised as they can just use the "forgotten password" functionality and reset it thanks to their access to your email.

And that is why I have a 2FA app for my email.


YES, this is what I have been waiting for. A month ago I lost a USB with my keepass file on it. The file is encrypted with a good password but I would feel better if I could reset all my passwords just in case but that would take me days.

After learning about this a few days ago, I created a Laravel package for managing .well-known URLs: https://github.com/tnorthcutt/laravel-well-known

I plan to add other URLs that make sense as well.


It up to browser standards to make this thing reality. example.com does not have any incentive to provide this url. However, if a users browser would treat sites implementing this feature as "more secure", example.com will gladly implement it.

I was looking to do this for my pass-rotate project:

https://github.com/ddevault/pass-rotate/issues/1

I hope a spec gains traction.


You really only have one password for web sites with password resets via email and that's the password to log into your email account.

I'd rather we hade /.well-known/delete-account

Note to self, create some express middleware that listens to .well-known GETs and redirects to a map of developer-supplied URLs.

But works only on Apple devices..so in a very small amount of devices

Allow me to change username/email while I'm at it!

How about a well-known URL for unsubscribe?

Not quite the same thing, but there are official email headers for unsubscribing from email mailing lists. https://tools.ietf.org/html/rfc2369

Don't we have AI by now that can figure out what button to click to change the password?

[flagged]


And?

To be pedantic, 'well known' things are not usually specified in advance :D

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.)


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.


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.


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.


GRC is not known for giving much importance to marketing.

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.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: