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

Hi there:

Automation in the changing of passwords in a password manager seems to be a
very useful idea. Like a swiss knife, it also might raise some concerns.

For this reason, I'd like stress one of the goals in the "sketch" of Mike
West "Password Change Automation" collection of interesting ideas:
"Accounts protected by second-factor authentication mechanisms should be
able to reauthenticate a user before their password is changed."

I would feel safer if I could auto-update my passwords with my
password-manager only in the accounts where I have 2FA enabled, and the
update mechanism requires the second factor. This way I'd know no-one (not
even the password manager) can update my passwords without getting a hold
of my yubikey or whatever second factor I'm using.

Kind regards,

--
nVotes' CTO           https://nvotes.com
Eduardo Robles      +1(831) 778-4140

On 4 April 2018 at 09:18, Mike West <mkwst@google.com> wrote:

> Hey John!
>
> I think this is a pretty reasonable thing to do, and I'll chat with
> Chrome's password management folks to see if they're interested in the
> same. Have you thought about how you'd expose this functionality to your
> user? I suppose you'd need to prefetch the endpoint to see if it returned
> anything useful, for example?
>
> That said, I share Brad's opinion that it would be possible to do a bit
> more if we have server-side cooperation, and that there's real value in
> creating more opportunities for that kind of cooperation. I'd sketched out
> an automated password-changing mechanism a while back (
> https://mikewest.github.io/change-password/), which might be a reasonable
> place to start the conversation for something more robust if that's
> something in which folks end up being interested.
>
> -mike
>
> On Wed, Apr 4, 2018 at 7:16 AM Brad Hill <hillbrad@gmail.com> wrote:
>
>> I'd love the option for this to be just a bit more sophisticated.
>> Discovery of the password change resource is just the first part of the
>> authentication discoverability problem.  I'd argue that 2FA is a much
>> bigger one.  It's been a dormant pet project of mine to write an browser
>> extension that notifies users when 2FA is available on a site, and directs
>> them to the appropriate settings page.  It would be even better if the well
>> known resource could be authenticated and offer an indication of whether
>> and what kind of 2FA is on, and the availability of advanced features like
>> U2F or WebAuthentication.  This would allow the extension (and eventually
>> the browser) could show the user a traffic light or similar for their
>> security posture and encourage 2FA adoption.  e.g. if the browser knows
>> you've used U2F on one site, it can notify you when you visit somewhere
>> else where you could use it, without having to disclose that you are a U2F
>> user to the site so they could make the promotion themselves.
>>
>> On Tue, Apr 3, 2018 at 9:04 PM John Wilander <wilander@apple.com> wrote:
>>
>>> Hi Jeffrey!
>>>
>>> On Apr 3, 2018, at 8:45 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>>
>>> I don't have a strong opinion about this, but have any existing password
>>> managers or websites given you feedback about how they'd use this proposal?
>>> For example, LastPass has an "Auto Change Password" option. Would this be
>>> enough to help that work in more cases, or do they need something more
>>> structured at the endpoint?
>>>
>>>
>>> We run a popular password manager ourselves which is where this proposal
>>> originates. In addition, we have discussed it with one other password
>>> manager. Rather than speak for them I’ll see if I can get them to comment
>>> straight to the list.
>>>
>>> Maybe we have password manager folks on the list already? Would this
>>> well-known location be useful to you?
>>>
>>>    Regards, John
>>>
>>>
>>> Jeffrey
>>>
>>> On Tue, Apr 3, 2018 at 4:32 PM John Wilander <wilander@apple.com> wrote:
>>>
>>>> Hi WebAppSec!
>>>>
>>>> We’re thinking of proposing a well-known URL location where users can
>>>> change their password or other credentials. Since this working group owns
>>>> the Credential Management spec, we’d like to get your feedback before we
>>>> email wellknown-uri-review@ietf.org.
>>>>
>>>> # The problem
>>>> When a password/credential manager wants to facilitate a user updating
>>>> their credentials, there isn't a good way to determine which part of the
>>>> relevant website to send the user to or to signal to the website that the
>>>> user's intent is to modify their credentials.
>>>>
>>>> # The proposal
>>>> https://example.com/.well-known/modify-credentials as a well-known URL
>>>> endpoint that signals user intent to modify their credentials. The web
>>>> server can serve a page at this location or do an HTTP or client-side
>>>> redirect. The location should be restricted to HTTPS, including any
>>>> redirects. RFC5785 doesn’t mention scheme restrictions but hopefully we can
>>>> work that out with the reviewers.
>>>>
>>>> What are your thoughts?
>>>>
>>>>    Regards, John
>>>>
>>>