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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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?

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

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?

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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?

> 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

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.

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.

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.