6 ms·

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 manage

• dmurray 8y 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. [0]https://support.dashlane.com/hc/en-us/articles/202699281-How-to-use-Password-Changer#title3 https://support.dashlane.com/hc/en-us/articles/202699281-How...
  • toyg 8y 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 8y 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.
• asdkhadsj 8y 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.
  • buster 8y 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" https://blabla.com/change-password" or whatever a password change request would look like?
    • WorldMaker 8y ago
      That "simpler implementation" of PUT https://example.com/magic-api/change-password 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 https://example.com and maybe eliminate the password entirely from the equation while we are at it.
      • buster 8y 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 8y 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".
• codeulike 8y ago
  Why not? Complexity.
  • hannob 8y 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 8y 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.
• Someone1234 8y 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.
  • tzs 8y 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?
  • madamelic 8y 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.
• wpietri 8y 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 8y 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.
• chias 8y 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.
• nathcd 8y ago
  For a polyfill of this functionality, check out pass-rotate: https://github.com/ddevault/pass-rotate https://github.com/ddevault/pass-rotate
• dec0dedab0de 8y 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 8y ago
    Don’t forget CORBA support! It’s a must have.
• notatoad 8y 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.
  • hannob 8y 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.
  • orblivion 8y 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.
• groestl 8y 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 ;)