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.
This project is something that will take approximately 5 minutes to implement, and probably not much more to design the "spec" in the first place. and as is, it does something worthwhile. A huge complex project in a related area isn't a replacement or an alternative, just a tangentially related thing that should have no bearing on this project. A .well-known url for password changes can provide real benefit for real people now, even though it doesn't do everything.
I also have taken 5 minutes to implement it in a system that I'm responsible for already.
Next on that list would be "update my payment methods". Of course websites love complicating our lives by hiding it in multiple different places, so that may be of limited utility.
Ie, as a dumb example, why should I expect them to implement an API for my password manager, and instead not simply allow oauth where my pass manager becomes my token provider?
Doesn't that fake example solve both problems, while also getting rid of bizarre password churn? Sure, it has the downside of "what happens when my password provider is compromised.." but that's always true, right?
An API for password managers feels like a solution to a problem we've created.
Don't get me wrong, I love the idea of reducing password churn. I'm just not sold on this specific method of handling it.
> simply allow oauth where my pass manager becomes my token provider
to be a simpler implementation then "PUT https://blabla.com/change-password" or whatever a password change request would look like?
The other poster is correct that immediately people would jump to using OAuth as one solution to manage which password manager apps can access that change password flow somewhat securely. At which, yes, why not just invert the OAuth flow and find better ways to make the Password Manager the provider rather than https://example.com and maybe eliminate the password entirely from the equation while we are at it.
Replay what? Me setting my password over HTTPS? How?
The sample URL was deliberately just an example. It would surely need more thought but i'm pretty sure the "PUT ..." solution is simpler then throwing oAuth at the problem.
So you're confident that the same people who can't secure the simple PUT request are better suited to implement the custom oAuth solution you are talking about? And that will be secure? I'd bet against that.
You need CSRF tokens to avoid replay attacks. You need some way for an app to Authorize: that they have permission to update someone's password. That's probably some sort of application whitelist. That application whitelist probably needs a permissions flow for a user to agree that Password Manager Brand X is indeed their password manager application of choice. Do we have a standard for such permission flows and app-specific bearer tokens? Oh look, it's OAuth that says "hi".
This scares me. Are you proposing it as something that is necessary, or something that is necessary as part of the parent poster's suggestion to use HTTPS + PUT? If the former, how does this scale across the multiple platforms I use? Ugh. Scary.
You are right, it doesn't scale well.
To me (and one of the posters above) it's just more proof that password infrastructure in general doesn't scale very well (because security attack surface scales proportionally), and that we really need a better solution. "Simple password change HTTP PUT REST API standard" is a security nightmare, and we should all be afraid of the mere idea of it. We should instead be looking to get rid of passwords altogether, for something that maybe does scale better. Such as the suggestion above that it would be better to try to sketch an API that asks our password/token managers to log us in, rather than the other way around, like an SSH Agent or an OAuth/OpenID provider or some better standard we could attempt to devise.
- You don't need "persmissin flows"
- You don't need "to update *someone's password" (just your own!)
- You don't need an "application whitelist" because HTTP doesn't know what an application is
Good password change forms have had CSRF tokens for decades now: https://en.wiktionary.org/wiki/CSRF_token
There are many known attacks whereby an attacker changes someone's password to control an account.
I don't care about OAuth at all. It's not an "OAuth mindset", it's a "I wouldn't trust a website at all in 2018 if it had an unsecure PUT endpoint to change my password" mindset.
HTTPS alone is not sufficiently secure. It's a start, but it is nowhere near enough on its own. SSL MITM attacks and Phishing are still problems today.
Requiring my current password isn't necessarily sufficient either: password cracking botnets exist. If the first sign that your password was cracked is that your password was changed to something only your attacker knows, that's not great. This is also where replay attacks come in. An attacker MITM or phishes this endpoint, and social engineers you into thinking you need to change your password, they get your old and new password together in one nice bundle.
Cookies aren't a sufficient answer for similar reasons. Again, take a look at cross-site request forgery issues and the history of replay attacks on password forms.
Application whitelists are a minimal security precaution to mitigate some botnets and phishing algorithms. HTTP does know what an application is, we often see application blacklisting done the hard way with User Agent strings and IP address ranges. Whitelisting is a more secure approach, but a lot harder to do securely (and why we have standards like OAuth; OAuth isn't the only answer, it's just the current easiest answer).
But that's my point. Keep it simple, let my password manager (be it on my mobile, laptop or whereever i want) change my password! Yes, i'd like that.
You don't even need that CSRF token, i don't know why. To prove your identity you'll only need to prove that you know you your password. That's possible, securely. See https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... and https://en.wikipedia.org/wiki/Zero-knowledge_password_proof
Why do you need an application whitelist?! The website i am visiting isn't whitelisting my browser, so why would it need to whitelist my password manager?
Can you point me to some source for botnets which crack passwords? I would be surprised. It's not feasible to brute-force a password over HTTP.
That's just one account I see as currently most at risk. There are plenty of others I'm concerned about as well.
Passwords are fragile, brittle things. "Simple" security is no longer an answer when dealing with passwords. FULL STOP. It's time we moved past passwords altogether, but even where we can't, we absolutely have to be serious about password security from top to bottom.
You can victim blame "hacked websites" for "badly implemented security" all you want, but that's part of the point, too. Password infrastructure will always be lowest common denominator, because it is "easy", because it is "simple". Everyone thinks they can implement password security, and everyone is wrong. There are still people that don't hash, much less salt, their passwords in 2018. There are still people that don't realize "Security Questions" are Plaintext Passwords and a giant security risk. In the age of bitcoin mining there is no such thing as a hashed or salted password that cannot be brute forced. Bitcoin mining is password brute force at massive scale, and dropped rainbow table hardware to the price floor.
I'm sorry that you still have any illusions left that passwords are and/or can be "simple". Passwords are dead and yet we're all going to be fighting that forest fire for decades to come.
[1] Which admittedly, is a possibility, but it would be a surprising shock for an application as big as Steam.
Unfortunately its not a well-known api endpoint.
I don't know what features U2F tokens support, but if they can be password protected I don't see why U2F being the only auth factor would be bad. You could even have the token itself attest to being password protected so you could require that of users before allowing them to disable non-U2F passwords.
Implementing some API spec that itself lets you change passwords for each one? No thank you, I have more important things to do.
The current system puts more work onto the password managers themselves, but realistically even if there was a generic API, the sites themselves aren't generic, each one requires a different series of steps with unique error messages, etc. So while an API would save some work, password managers would still need bespoke steps per site.
Couldn't the former use the latter?
Seems like the issue isn't the idea, it's the way they're implementing it.
Shouldn't it be ui(api(pwd changing code)), not ui(pwd changing code) + api(pwd changing code)?
> even if there was a generic API, the sites themselves aren't generic, each one requires a different series of steps with unique error messages
Again this sounds like an implementation issue, not an idea issue.
People can use all of kinds of weird status codes if they like as long as they implement 200, 401 and 500. Those three cover the bases.
And I don't think the proposal covers any site-specific options and could standardize on key naming (`email`, `password`, `username`, etc) Password managers already keep this info and more, I think LastPass will even store your credit cards and has profiles so you can swap between business, personal and other info.
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 ;)
[0]https://support.dashlane.com/hc/en-us/articles/202699281-How...
The alternative of doing a full API takes much more effort and therefore has little chance of adoption.