A well-known URL for changing passwords
github.com
github.com
> 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
http://www.bacnet.org/Addenda/Add-135-2012am-ppr3-draft-17_c...
/.well-known/delete-account
/.well-known/request-user-data
Isn't this mandated to be present and accessible by the GDPR anyway?
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.
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.
You could have that plugin have a database of sites and also provide easy links for those sites that try to hide those functions.
We are a non profit, and don't run from user donations.
And regarding more legislation, no thanks.
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.
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).
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?
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
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.
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.
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.
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.
At last wrt. login and register for doing the "first" auth which is then stored in the authenticator, e.g. a username/password login).
These are all relatively common business requirements.
The web already has a perfectly good solution for arbitrary forms, and has had it for decades. Just use that.
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?
/.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.
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.
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.
See: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird...
Already do special handling of acme-challenge for Let's Encrypt/ACME but that's a given.
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.
which would explain why apple has implemented it...
E.g.,
$ gpg --lookup-key foo@example.org
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.
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.
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.
[0]https://support.dashlane.com/hc/en-us/articles/202699281-How...
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.
> 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?
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.
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.
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".
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.
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.
- 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
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).
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?
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's just one account I see as currently most at risk. There are plenty of others I'm concerned about as well.
Passwords are fragile, brittle things. "Simple" security is no longer an answer when dealing with passwords. FULL STOP. It's time we moved past passwords altogether, but even where we can't, we absolutely have to be serious about password security from top to bottom.
You can victim blame "hacked websites" for "badly implemented security" all you want, but that's part of the point, too. Password infrastructure will always be lowest common denominator, because it is "easy", because it is "simple". Everyone thinks they can implement password security, and everyone is wrong. There are still people that don't hash, much less salt, their passwords in 2018. There are still people that don't realize "Security Questions" are Plaintext Passwords and a giant security risk. In the age of bitcoin mining there is no such thing as a hashed or salted password that cannot be brute forced. Bitcoin mining is password brute force at massive scale, and dropped rainbow table hardware to the price floor.
I'm sorry that you still have any illusions left that passwords are and/or can be "simple". Passwords are dead and yet we're all going to be fighting that forest fire for decades to come.
[1] Which admittedly, is a possibility, but it would be a surprising shock for an application as big as Steam.
Unfortunately its not a well-known api endpoint.
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.
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.
Couldn't the former use the latter?
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.
The alternative of doing a full API takes much more effort and therefore has little chance of adoption.
Implementing some API spec that itself lets you change passwords for each one? No thank you, I have more important things to do.
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 also have taken 5 minutes to implement it in a system that I'm responsible for already.
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.
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 ;)
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?
What is that a quote from? I cannot find it in the spec here:
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?
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).
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.
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.
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.
It's not expediency, it's laziness bordering on criminal stupidity/negligence.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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...
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.
> 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?
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.
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).
> 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.
I did. My confusion arose from it. Something is clear to you that is not to me :)
/.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...
seriously though, I would love this for all those sites that bury it as far as possible...
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?
I plan to add other URLs that make sense as well.
https://github.com/ddevault/pass-rotate/issues/1
I hope a spec gains traction.
(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.)
Though I think he will need a more convincing marketing site if he intends for people to try it out.
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.
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.
Every single site needing its own password is a feature, not a bug. Educate people about password managers instead.