W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2018

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

From: Brad Hill <hillbrad@gmail.com>
Date: Wed, 04 Apr 2018 21:45:06 +0000
Message-ID: <CAEeYn8h9czie6gac+jaz_Vs+Qb67w3mykh3i1NoQOr0Hm_SogQ@mail.gmail.com>
To: "Mike O'Neill" <michael.oneill@baycloud.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, John Wilander <wilander@apple.com>, Jeffrey Yasskin <jyasskin@google.com>, public-webappsec@w3.org
I'm thinking it might return a JSON dictionary with the urls where the user
can change their password or update 2FA settings.

One of those URLs might list an endpoint for a password change URL service
that conforms to a interoperably defined API such that it can be done in an
automated fashion by a password manager.

If authenticated, the dictionary might also include whether you have 2FA
enabled, and what kind of 2FA.  I don't think the abuse cases for this are
very risky.  If it's only returned same-origin and authenticated, then
presumably any attacker with access to this could also access the locations
where this information can be scraped and gain it by other means.  I think
the benefits of making 2FA settings discoverable and nudging people to turn
it on far outweigh the risks of removing a trivial reconnaissance cost for
an attacker already in a privileged position.  In many cases it is
trivially discoverable whether a user has 2FA enabled even from an
unauthenticated state since such prompts are often made even when an
incorrect password is entered, to avoid providing an oracle on that data.
And any site that worried about exposing this could simply choose not to
populate those members.

On Wed, Apr 4, 2018 at 12:46 PM Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> The DNT tracking status resource at /.well-known/dnt/ can be a redirect see
> https://w3c.github.io/dnt/drafts/tracking-dnt.html#status-resource
>
>
>
> *From:* Daniel Veditz <dveditz@mozilla.com>
> *Sent:* 04 April 2018 20:28
> *To:* John Wilander <wilander@apple.com>
> *Cc:* Brad Hill <hillbrad@gmail.com>; Jeffrey Yasskin <jyasskin@google.com>;
> public-webappsec@w3.org
> *Subject:* Re: Proposal:
> https://example.com/.well-known/modify-credentials
>
>
>
> On Wed, Apr 4, 2018 at 11:25 AM, John Wilander <wilander@apple.com> wrote:
>
> 1. Are you saying we should have additional well-known locations for these
> additional services?
>
> 2. Or are you saying we should have requirements on the markup of the page
> you end up on when loading .well-known/modify-credentials?
>
>
>
> ​My first reaction was that it seemed strange (and limiting!) to have a
> working web page at a .well-known address​, and especially strange for a
> .well-known address to be a redirect. Are there any others that behave that
> way?
>
>
>
> If instead it returned data about where to find the password change URL on
> the site we could easily add more information, such as the ones Brad
> suggested or where to find the programmatic log-in (no web page required)
> suggested in Mike's proposal.
>
>
>
> -
>
> ​Dan Veditz​
>
>
>
Received on Wednesday, 4 April 2018 21:45:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 April 2018 21:45:41 UTC