Re: Proposal: https://example.com/.well-known/modify-credentials

Hi Matt!

Thanks for your feedback.

> On Apr 9, 2018, at 5:55 PM, Mark Burnett <mb@xato.net> wrote:
> 
> On the surface this seems like a great idea, although I think that a meta tag and/or an HTTP header would be a slightly better (but still not perfect) way of handling this.
> 
> Having a well-known URL simplifies things considerably in one sense, but there are other risks you introduce. Here are my thoughts:
> 
> 1. You would only want to expose the URL within the authenticated scope of a web application. A public API or form might increase the attack surface and could be a good target for brute-force attacks. Since an API can't introduce a CAPTCHA or other prompt in response to a brute-force attack (not that that is a great strategy anyway), providing the endpoint only to authorized users would reduce that exposure. Yes, you can implement a check with a well-known URL and return an HTTP 403 as necessary, but that might not be consistent with the organization's best practices, routing mechanisms, or may not be easy to implement with a 3rd party CMS or other software. Having flexibility with the URL would be important in some cases and allows for easier management of this endpoint as part of the application available to authorized users. 
> 
> 2. On that same note, having an already-authorized user simplifies the standard. Proprietary MFA or challenge-response schemes that may require multiple requests to complete authentication or that require a smart card or client certificate greatly complicates any standardized protocol. It is much simpler to have a user authenticate to the application using whatever means and then only have to send the current password for the credentials API. A meta tag or HTTP header that points to a password management endpoint could be more flexible, possibly even providing a custom endpoint for each session. 
> 
> 3. It is also possible that a single service might have several authentication back-ends, depending on the type of user (i.e., business vs personal). You might not know which authentication back-end to use until the user has been identified. Like the previous two points, this could still be accomplished with a well-known URI, but not having to consider or duplicate the routing in the initial authentication step greatly simplifies things. 
> 
> 4. Then, there is the issue of a possible CSRF attack, especially in cases where a password manager or web browser might be storing the current password. With every application having the same endpoint, massive attacks might be easier to pull off. To prevent this, you would need the site to provide a unique token that must be available before submitting the password change request which means that it would need to be generated on every single page. Of course, you could leave it up to the developers to implement a token, and they might already have a system in place for doing that, but if left to the developers it may never get implemented so the protocol has potentially introduced new attack surface. Having the token a part of the meta tag or HTTP header makes the token an integral part of the specification. 
> 
> 5. Same as above but for phishing.

We are not proposing the well-known endpoint to be an API or web service. We are proposing that site owners either serve their existing “Reset password”/“Update credentials” page from the well-known location, or have the well-known location redirect the browser to the existing page. That page can use Captcha, CSRF protection, CSP, and any other security measures available to regular webpages.

The goal is to allow credential management tools to provide a better user experience than having the user manually navigate their way to the “Reset password”/“Update credentials” page.

Does that clarification address your concerns?

   Regards, John

> 
> 
> Mark Burnett
> 
> 
> On Mon, Apr 9, 2018 at 6:28 PM, Mark Burnett <mb@xato.net <mailto:mb@xato.net>> wrote:
> I was in the process of sending that last email and somehow hit the shortcut key for send while I was in the middle of rewriting my thoughts! Here is the real email:
> 
> 
> 
> On the surface this seems like a great idea, although I think that a meta tag and/or an HTTP header would be a slightly better (but still not perfect) way of handling this.
> 
> Having a well-known URL simplifies things considerably, but there are other risks you introduce. Here are my thoughts:
> 
> 1. You would only want to make the URL available within the authenticated scope of a web application. A public API would increase the attack surface and is a good target for brute-force attacks. Since an API can't introduce a CAPTCHA or other prompt in response to a brute-force attack (not that that is a great strategy anyway), providing the endpoint only to authorized users would reduce that exposure. Yes, you can implement a check with a well-known URL and return an HTTP 403 as necessary, but that might not be consistent with the organization's best practices, or may not be easy to implement with a 3rd party CMS or other software. Having flexibility with the URL would important in some cases. 
> 
> 2. Having an already-authorized user simplifies the standard. Proprietary MFA or challenge-response schemes that may require multiple requests to complete authentication or that require a smart card or client certificate greatly complicates any standardized protocol.. It is much simpler to have a user authenticate to the application using whatever means and then only send the password for the authentication API. 
> 
> 3. Then, there is the issue of a possible CSRF attack, especially in cases where a password manager or web browser might be storing the current password. In that case, you would need the site to provide a unique token, that must be available before submitting the password change request which means that it would need to be generated on every single page, which might complicate things. Of course, you could leave it up to the developers to implement a token, but in that case very few actually will so now the protocol has potentially introduced new attack surface. Furthermore, you would probably only want this URL to accept POST requests. Having the token an integral part of the meta tag or HTTP header makes the token an integral part of the specification. 
> 
> 
> 
> Mark Burnett
> 
> 
> 
> 
> 
> 
> On Mon, Apr 9, 2018 at 6:24 PM, Mark Burnett <mb@xato.net <mailto:mb@xato.net>> wrote:
> On the surface this seems like a great idea, although I think that a meta tag and/or an HTTP header would be a slightly better (but still not perfect) way of handling this.
> 
> Having a well-known URL simplifies things considerably, but there are other risks you introduce. 
> 
> 
> 1. You would only want to make the URL available within the authenticated scope of a web application. A public API would increase the attack surface and is a good target for brute-force attacks. Since an API can't introduce a CAPTCHA or other prompt in response to a brute-force attack (not that that is a great strategy anyway), providing the endpoint only to authorized users would reduce that exposure. Yes, you can implement a check with a well-known URL and return an HTTP 403 as necessary, but that might not be consistent with the organization's best practices, or may not be easy to implement with a 3rd party CMS or other software. Having flexibility with the URL would important in some cases. 
> 
> 2. Having an already-authorized user simplifies the standard. Proprietary MFA or challenge-response schemes that may require multiple requests to complete authentication or that require a smart card or client certificate greatly complicates any standardized protocol. It is much simpler to have a user authenticate to the application using whatever means reand then 
> 
> One solution is to make the URL available only to accounts that are already authenticated to the application, where you may only need the user's password as additional validation before initiating a password change. Any request that is not associated with a valid authenticated session would then automatically return an HTTP 403 error. 
> 
> Then, there is the issue of a possible CSRF attack, especially in cases where a password manager or web browser might be storing the current password. In that case, you would need the site to provide a unique token, that must be available before submitting the password change request which means that it would need to be generated on every single page, which might complicate things. Of course, you could leave it up to the developers to implement a token, but in that case very few actually will so now the protocol has potentially introduced new attack surface. Furthermore, you would probably only want this URL to accept POST requests. 
> 
> Now I know this is way beyond the scope of the original question, but presumably the whole reason for doing this is to allow for automated password changes. However, as we all know, security policies can be all over the place so any scheme would need to know policies on length, character set, age, etc. 
> 
> 
> 
> On Mon, Apr 9, 2018 at 1:12 PM, Daniel Veditz <dveditz@mozilla.com <mailto:dveditz@mozilla.com>> wrote:
> On Mon, Apr 9, 2018 at 9:21 AM, John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
> Native apps and password managers can just load the URL in the browser or an in-app WebView instead of fetching the JSON, parse it, and then load the page.
> 
> Browsers or general purpose apps have to load it once (or a HEAD request at least) to see if it exists before showing the user that it's an option​, and then load it again when the user selects it. You can't present a Log-in button that goes to a 404 page. A site-specific app could rely on that URL existing, but then it could just as easily have some other site-specific URL built-in.
> 
> But we don’t have strong opinions on this.
> 
> ​I don't either. I'll ask our password manager folks to chime in.
> 
> -Dan Veditz
> 
> 
>