WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#41636 closed enhancement (maybelater)

Disable LastPass save prompt in Customizer's password fields

Reported by: cliffpaulick Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9
Component: Customize Keywords:
Focuses: ui Cc:

Description

LastPass prompts to save passwords when using the Customizer if a "password" type of field is used in any loaded Customizer panel/section.

https://lastpass.com/support.php?cmd=showfaq&id=10512 details how to disable this from happening.

In my experience, the Customizer's password fields are usually used for things like Google Maps, weather, or other API Key, not actually a username and password (i.e. entering data one-time, not in a reuse/repeat sort of manner suitable for a password manager application).

You also don't want to tell LastPass to "never ask me again on this site" because you actually "do" want to have LastPass work on registration, login, and/or password reset pages.

Attachments (1)

For__41636___Disable_LastPass_prompts_for_Customizer_s__password__type_fields.patch (1.1 KB) - added by cliffpaulick 4 years ago.
Disable LastPass prompts for Customizer's 'password' field types

Download all attachments as: .zip

Change History (8)

@cliffpaulick
4 years ago

Disable LastPass prompts for Customizer's 'password' field types

#1 @westonruter
4 years ago

@cliffpaulick thanks for the patch. However, for core we'd want to only include something that is generic. We wouldn't want a LastPass-specific field. If there is a generic autocomplete="new-password" attribute that could be used instead, which would work with 1Password and Chrome's builtin password manager, that would be preferred.

In any case, you can disable LastPass specifically on your site for a given field by using the input_attrs array for a control.

For example, in a plugin you could do:

<?php
add_action( 'customize_register', function( WP_Customize_Manager $wp_customize ) {
        foreach ( $wp_customize->controls() as $control ) {
                /** @var WP_Customize_Control $control */
                if ( 'password' === $control->type ) {
                        $control->input_attrs['data-lpignore'] = 'true';
                }
        }
}, 1000 );

#2 @cliffpaulick
4 years ago

@westonruter, thanks so much for your thorough reply. Sorry for my delay getting back to you.

I've been playing around with this since my patch. LastPass actually isn't respecting its own custom tag, nor the autocomplete. I reported the bug to them months ago and haven't heard of a resolution yet.

Do you want me to add the autocomplete as you suggested?

#3 @westonruter
4 years ago

@cliffpaulick Only if it works. If adding autocomplete="new-password" actually has a benefit for password managers. If LastPass doesn't honor it, and 1Password doesn't honor it, and so on, then there wouldn't be much value.

#4 follow-up: @cliffpaulick
4 years ago

@westonruter
Per https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields

autocomplete="off" only works on forms, not fields, so I tried changing the <form> line in /wp-admin/customize.php to

<form id="customize-controls" class="wrap wp-full-overlay-sidebar" autocomplete="off">

and...

  • LastPass didn't prompt for password fields (yeah!), but the first text field (surprising!) was prompted to me. I'm guessing this is a bug on their end.
  • 1password still prompted for a password save on a password field (worse than LastPass) but never offered to save any text field (better than LastPass but unaffected by autocomplete="off")

So...

  • LastPass seems to respect autocomplete="off" (in a buggy way) even though their own support site documents a different way (per field, not form).
  • I found https://discussions.agilebits.com/discussion/comment/331839/#Comment_331839 where a 1password employee states that they purposefully ignore autocomplete="off" and says most other password managers do too. He said they wouldn't if site owners would use it correctly, but that it's abused (e.g. banks not wanting you to store your password).

Based on all this information, should autocomplete="off" be added to core's <form> -- because passwords aren't/shouldn't be set/updated via the Customizer, right? -- and then at least it'd be best practice even though password managers may not respect it?

#5 in reply to: ↑ 4 @westonruter
4 years ago

Replying to cliffpaulick:

Based on all this information, should autocomplete="off" be added to core's <form> -- because passwords aren't/shouldn't be set/updated via the Customizer, right? -- and then at least it'd be best practice even though password managers may not respect it?

I'm not sure about that. Autocomplete can be used for more than just passwords.

#6 @cliffpaulick
4 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

Gotcha. Sounds like just close the ticket then. Thanks for the help and quick replies.

#7 @westonruter
4 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.