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.
A well-known URL for changing passwords
91–100 of 179 posts
Re: A well-known URL for changing passwords
#92I haven't read the proposal but it made me think of something like:
/.well-known/personal-access-token
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...
Re: A well-known URL for changing passwords
#93Earlier quoted context omitted.
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 passwor…
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'…
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".
Re: A well-known URL for changing passwords
#94That 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.
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…
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.
Re: A well-known URL for changing passwords
#95Can 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).
Re: A well-known URL for changing passwords
#96To be pedantic, 'well known' things are not usually specified in advance :D
Re: A well-known URL for changing passwords
#97Can 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 re…
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.
Re: A well-known URL for changing passwords
#98Earlier quoted context omitted.
> 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…
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 permissi…
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
Re: A well-known URL for changing passwords
#99This 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.
Re: A well-known URL for changing passwords
#100Earlier quoted context omitted.
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 permissi…
"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.
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.