4 ms·

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 dum

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".
      - johnjohnsmith 8y 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 8y 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 8y 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 8y 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.
tetrep 8y 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.
deleted 8y ago
[deleted]

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".
    - johnjohnsmith 8y 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 8y 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 8y 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 8y 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.

tetrep 8y 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.

deleted 8y ago

[deleted]