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

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

From: John Wilander <wilander@apple.com>
Date: Mon, 09 Apr 2018 09:14:00 -0700
Message-id: <4C2D93DA-E2A0-4068-8B2F-BF280539F927@apple.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
To: Mark Nottingham <mnot@mnot.net>
Hi again Mark!

> On Apr 4, 2018, at 4:38 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
>>> We don’t want to cache or save specific locations since they may get stale, stateful things tend to become tracking vectors, and an HTML element sounds like a phishing injection vector.
> 
> Thinking about this more -- I'm not sure why this merits a well-known location. Everything else that the password manager knows about the login interface, it gets from the login page, correct? If so, it seems like putting this information there doesn't introduce any new security issues (since an XSS, etc. there is going to compromise the account anyway).

I’m not sure all password managers save which page you log in on. There may be multiple of them per origin or a header-like login avatar/button on every page. In addition, the login page may go stale for a seldom-used account, typical for the reset password scenario.

> Tracking doesn't seem like a relevant concern -- as long as the user has an account at the site, that's a far easier way to track the users' activity.

I was thinking of two tracking scenarios:
A bogus modify credentials link, only used for tracking.
A modify credentials link used to track users when they are deliberately logged out.
Now, if there’s a way to detect that the password manager has cached that link, it’s a tracking vector. Do it for multiple origins and you may have a bit string tracking ID. This is not something thought out. I just know from experience that whenever a site can make a browser store something, someone figures out how to abuse it as a tracking vector. 🙁 With a well-known location that’s equal for all, it’s stateless.

   Regards, John
Received on Monday, 9 April 2018 16:14:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 April 2018 16:14:29 UTC