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

 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.


Mark Burnett


On Mon, Apr 9, 2018 at 6:28 PM, Mark Burnett <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> 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>
>> wrote:
>>
>>> On Mon, Apr 9, 2018 at 9:21 AM, John Wilander <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
>>>
>>
>>
>