- From: Brad Hill <hillbrad@gmail.com>
- Date: Wed, 04 Apr 2018 21:45:06 +0000
- 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
- Message-ID: <CAEeYn8h9czie6gac+jaz_Vs+Qb67w3mykh3i1NoQOr0Hm_SogQ@mail.gmail.com>
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