A well-known URL for changing passwords


749 points | by fanf2 256 days ago


  • gregmac 256 days ago

    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

    • hoppelhase 255 days ago

      How about something like:

      This would also be nice as we wouldn't need things like https://justdelete.me
      • dfabulich 255 days ago

        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.

        • onion2k 255 days ago

          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.

          • brokenmachine 252 days ago

            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.

          • hoppelhase 255 days ago

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

            • ygra 255 days ago

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

              • landon32 255 days ago

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

              • TeMPOraL 255 days ago

                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.

                • Symbiote 255 days ago

                  My employer would have no problem with it.

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

                • caseysoftware 255 days ago

                  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.

                  • jimmcslim 255 days ago

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

                  • dgut 255 days ago

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

                    And regarding more legislation, no thanks.

                  • Immortalin 255 days ago

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

                    • zamalek 255 days ago

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

                      • tomjakubowski 255 days ago

                        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?

                    • greycol 255 days ago

                      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:


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


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

                      • peterwwillis 256 days ago

                        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?

                        • WorldMaker 256 days ago

                          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.

                          • peterwwillis 255 days ago

                            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.

                            • delinka 255 days ago

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

                              • WorldMaker 255 days ago

                                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.

                                • peterwwillis 255 days ago

                                  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.

                                  • _jal 255 days ago

                                    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.

                            • nine_k 256 days ago

                              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.

                              • dathinab 255 days ago

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

                                • CuriousSkeptic 255 days ago
                                  • marcosdumay 255 days ago

                                    Why not use simple HTTP authentication?

                                    • munk-a 255 days ago

                                      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.

                                      • geofft 255 days ago

                                        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.

                                      • tedunangst 255 days ago

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

                                        • oneeyedpigeon 255 days ago

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

                                      • therealtbs 256 days ago

                                        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

                                        • hober 250 days ago
                                        • isostatic 256 days ago

                                          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


                                          How widely adopted are these?

                                          • tzs 255 days ago

                                            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.


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

                                            • Leace 255 days ago

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

                                            • ushi 256 days ago
                                              • devman0 255 days ago
                                                • Someone1234 256 days ago

                                                  The one that Apple's browsers request on every domain isn't even in the list:


                                                  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.

                                                  • WorldMaker 255 days ago

                                                    WebFinger, a key underlying tech of the Fediverse and used for bootstrapping OpenID Connect, ActivityPub, and many other standards uses .well-known.


                                                    • eponeponepon 256 days ago

                                                      I think LetsEncrypt uses it, no?

                                                      • webignition 256 days ago

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

                                                        • JeremyBanks 256 days ago

                                                          Yes, also Keybase.

                                                          • toupeira 256 days ago

                                                            Yes, also OpenID Connect.

                                                            • merb 256 days ago

                                                              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.

                                                          • xena 256 days ago
                                                            • Someone1234 256 days ago

                                                              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.

                                                              • geofft 255 days ago

                                                                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.

                                                                • saagarjha 255 days ago

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

                                                            • mikeleung 255 days ago

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


                                                              which would explain why apple has implemented it...

                                                              • hober 255 days ago

                                                                Yup, hi.

                                                                • intern4tional 255 days ago

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

                                                              • codeulike 256 days ago

                                                                they are not well known

                                                                • jtl999 256 days ago

                                                                  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.

                                                                  • tialaramex 255 days ago

                                                                    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.

                                                                  • dandr01d 256 days ago


                                                                  • hannob 256 days ago

                                                                    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.

                                                                    • notatoad 255 days ago

                                                                      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.

                                                                      • orblivion 255 days ago

                                                                        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.

                                                                        • hannob 255 days ago

                                                                          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.

                                                                        • asdkhadsj 256 days ago

                                                                          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.

                                                                          • tetrep 256 days ago

                                                                            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.

                                                                            • buster 256 days ago

                                                                              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?

                                                                              • WorldMaker 256 days ago

                                                                                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.

                                                                                • buster 255 days ago

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

                                                                                  • WorldMaker 255 days ago

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

                                                                                    • buster 255 days ago

                                                                                      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.
                                                                                      • WorldMaker 255 days ago

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

                                                                                        • buster 255 days ago

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

                                                                                          • WorldMaker 254 days ago

                                                                                            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.

                                                                                            • buster 254 days ago

                                                                                              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.

                                                                                              • WorldMaker 251 days ago

                                                                                                My Steam account has had high entropy, sole use passwords cracked in the timeframe of months, which would seem to indicate (if Valve is not leaking [1]) a botnet using their "simple" HTTPS login endpoints to brute force passwords. So far Steam Guard (2FA) has stopped the attacks, but that doesn't make me feel that much better given the speed in which the passwords seem to be cracking.

                                                                                                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.

                                                                                      • johnjohnsmith 255 days ago

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

                                                                                        • WorldMaker 255 days ago

                                                                                          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.

                                                                                  • SpaceNugget 255 days ago

                                                                                    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.

                                                                                    • asdkhadsj 254 days ago

                                                                                      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.

                                                                                • chias 255 days ago

                                                                                  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.

                                                                                  • Someone1234 256 days ago

                                                                                    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.

                                                                                    • madamelic 255 days ago

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

                                                                                      • tzs 255 days ago

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

                                                                                      • groestl 255 days ago

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

                                                                                        • dmurray 256 days ago

                                                                                          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.


                                                                                          • toyg 255 days ago

                                                                                            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.

                                                                                            • dmurray 255 days ago

                                                                                              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.

                                                                                          • wpietri 256 days ago

                                                                                            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?

                                                                                            • tree_of_item 255 days ago

                                                                                              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.

                                                                                            • codeulike 256 days ago

                                                                                              Why not? Complexity.

                                                                                              • hannob 256 days ago

                                                                                                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.

                                                                                                • codeulike 256 days ago

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

                                                                                              • nathcd 255 days ago

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

                                                                                                • dec0dedab0de 255 days ago

                                                                                                  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

                                                                                                  • aaaaaaaaaab 255 days ago

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

                                                                                                • Someone1234 256 days ago

                                                                                                  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?

                                                                                                  • Ajedi32 256 days ago

                                                                                                    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?

                                                                                                    • Someone1234 256 days ago

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

                                                                                                      • Ajedi32 256 days ago

                                                                                                        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.

                                                                                                        • therealtbs 256 days ago

                                                                                                          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.

                                                                                                        • pmontra 256 days ago

                                                                                                          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.

                                                                                                          • toyg 255 days ago

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

                                                                                                          • CGamesPlay 256 days ago

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

                                                                                                            • zeroimpl 253 days ago

                                                                                                              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.

                                                                                                              • Someone1234 256 days ago

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


                                                                                                                • CGamesPlay 256 days ago

                                                                                                                  Sorry, intended as a hypothetical suggestion, not a quote.

                                                                                                                  • Someone1234 256 days ago

                                                                                                                    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.

                                                                                                              • hober 250 days ago
                                                                                                              • curo 255 days ago

                                                                                                                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.

                                                                                                                • pc86 255 days ago

                                                                                                                  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.

                                                                                                                  • jmeyer2k 255 days ago

                                                                                                                    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.

                                                                                                                    • kingo55 255 days ago

                                                                                                                      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.

                                                                                                                      • kibibu 255 days ago

                                                                                                                        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)

                                                                                                                        • dancek 255 days ago

                                                                                                                          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.

                                                                                                                          • ric2b 255 days ago

                                                                                                                            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.

                                                                                                                            • kibibu 255 days ago

                                                                                                                              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.

                                                                                                                              • frenchy 255 days ago

                                                                                                                                Who uses MD5 for hashing password anymore?

                                                                                                                                • pc86 255 days ago

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

                                                                                                                          • pc86 255 days ago

                                                                                                                            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.

                                                                                                                          • hamandcheese 255 days ago

                                                                                                                            Or maybe just ignorance?

                                                                                                                            • pc86 255 days ago

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

                                                                                                                              • dragonwriter 255 days ago

                                                                                                                                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.

                                                                                                                            • jstarfish 255 days ago

                                                                                                                              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.

                                                                                                                              • lotyrin 255 days ago

                                                                                                                                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.

                                                                                                                                • tialaramex 255 days ago

                                                                                                                                  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.

                                                                                                                                  • acdha 255 days ago

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

                                                                                                                                  • kingo55 255 days ago

                                                                                                                                    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.

                                                                                                                                • tracker1 253 days ago

                                                                                                                                  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.

                                                                                                                                • JackC 256 days ago

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

                                                                                                                                  • Klathmon 256 days ago

                                                                                                                                    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.

                                                                                                                                  • ghostly_s 255 days ago

                                                                                                                                    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?

                                                                                                                                    • TazeTSchnitzel 255 days ago

                                                                                                                                      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.
                                                                                                                                      • ghostly_s 254 days ago

                                                                                                                                        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.

                                                                                                                                      • hober 250 days ago
                                                                                                                                      • crescentfresh 255 days ago

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

                                                                                                                                        • intertextuality 255 days ago

                                                                                                                                          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.

                                                                                                                                        • hober 250 days ago
                                                                                                                                        • juancampa 255 days ago

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


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

                                                                                                                                          • wolfgang42 256 days ago
                                                                                                                                            • pbnjay 256 days ago

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

                                                                                                                                              • NickBusey 256 days ago

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

                                                                                                                                              • ancorevard 256 days ago

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

                                                                                                                                                • soheil 255 days ago

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

                                                                                                                                                • soheil 255 days ago

                                                                                                                                                  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.

                                                                                                                                                  • masa331 255 days ago

                                                                                                                                                    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

                                                                                                                                                    • epse 255 days ago

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

                                                                                                                                                      • Rjevski 255 days ago

                                                                                                                                                        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.

                                                                                                                                                        • tracker1 253 days ago

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

                                                                                                                                                    • noResetPage 255 days ago
                                                                                                                                                      • tnorthcutt 255 days ago

                                                                                                                                                        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.

                                                                                                                                                        • ndnxhs 255 days ago

                                                                                                                                                          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.

                                                                                                                                                          • janikvonrotz 255 days ago

                                                                                                                                                            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.

                                                                                                                                                            • Sir_Cmpwn 256 days ago

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


                                                                                                                                                              I hope a spec gains traction.

                                                                                                                                                              • nly 255 days ago

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

                                                                                                                                                                • choward 255 days ago

                                                                                                                                                                  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.

                                                                                                                                                                  • andrethegiant 255 days ago

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

                                                                                                                                                                    • IloveHN84 255 days ago

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

                                                                                                                                                                      • michaelmcmillan 255 days ago

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

                                                                                                                                                                        • edanweis 255 days ago

                                                                                                                                                                          How about a well-known URL for unsubscribe?

                                                                                                                                                                        • amelius 255 days ago

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

                                                                                                                                                                          • janzij 256 days ago


                                                                                                                                                                          • polemic 255 days ago

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

                                                                                                                                                                            • gwbas1c 256 days ago

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

                                                                                                                                                                              • avaika 256 days ago

                                                                                                                                                                                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.

                                                                                                                                                                                • opless 256 days ago

                                                                                                                                                                                  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.

                                                                                                                                                                                  • 0xfeba 256 days ago


                                                                                                                                                                                    Though I think he will need a more convincing marketing site if he intends for people to try it out.

                                                                                                                                                                                    • Piskvorrr 255 days ago

                                                                                                                                                                                      GRC is not known for giving much importance to marketing.

                                                                                                                                                                                    • Tharkun 256 days ago

                                                                                                                                                                                      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.

                                                                                                                                                                                      • Piskvorrr 255 days ago

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