3 ms·

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

by 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.
- buster 8y 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 8y 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 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 8y ago

by buster 8y ago

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.
buster 8y 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 8y 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 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 8y ago