Make WordPress Core

Opened 3 years ago

Closed 3 weeks ago

#55228 closed feature request (invalid)

Provide Option to Remove Password Visibility Button and Dashicons from WordPress' Login Form

Reported by: generosus's profile generosus Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.9.1
Component: Security Keywords: 2nd-opinion close dev-feedback
Focuses: Cc:

Description

Request:

I would like to recommend adding a feature to WordPress that will allow the removal of WordPress' login form password visibility button (toggle) and dashicons (eyes).

Details:

https://ibb.co/Xp2Mh8P

Reasons:

(1) Security Enhancement

(2) Cleaner UI

Implementation:

(1) Add a new checkbox field label, titled "Login Form", with the following checkbox text: "Disable Password Visibility Button and Dashicons" to WordPress Dashboard > Settings > General

(2) When the checkbox is selected, the code associated with the password visibility button and dashicons is removed, or, activates the code snippet [provided here]https://wordpress.org/support/topic/help-appreciated-remove-visibility-eye-dashicon-from-wp-login-form/.

Scenario:

A website Administrator goes to his/her WordPress login page and login form is auto-filled by the browser but the "Log In" button is never clicked. Suddenly, the Administrator is summoned away from his/her desk leaving open the opportunity for a co-worker, visitor, disgruntled employee, or "hacker in disguise" to click the password visibility button thus exposing critical website login information. A quick toggle back to "hidden" by the perpetrator and the Administrator will never know what happened.

Conclusion:

By implementing this feature request, WordPress is offering its Administrators an optional, valuable login security layer.

Thank you for reading!

Change History (4)

#1 @generosus
3 years ago

  • Summary changed from Provide Option to Remove Password Visibility Button and Dashicons form WordPress' Login Form to Provide Option to Remove Password Visibility Button and Dashicons from WordPress' Login Form

#2 follow-up: @dd32
3 years ago

  • Keywords close added; dev-feedback removed

A website Administrator goes to his/her WordPress login page and login form is auto-filled by the browser but the "Log In" button is never clicked.

If a browser is prefilling the password, an attacker can gain access to the data within the password field relatively fast even without the button (I just timed it at 10seconds without using the button). Physical access and choosing to use a password-manager which auto-fills is an instant situation where nothing WordPress does will 'protect' the user.

This seems like plugin territory to me, if a site owner wishes to disable this functionality then doing so through a plugin seems like the best option to me.

It's also against the WordPress philosophy of Decisions, not options.

I'm adding close here to signify that I think this should be closed as wontfix but that 2nd-opinion from others is still warranted.

#3 in reply to: ↑ 2 @generosus
3 years ago

  • Keywords dev-feedback added

Replying to dd32:

It's also against the WordPress philosophy of Decisions, not options.


Excellent point. I'm all for simplicity. "Complicating things is easy, keeping them simple is not." - Richard Branson

This seems like plugin territory to me, if a site owner wishes to disable this functionality then doing so through a plugin seems like the best option to me.


After further research and your valuable feedback, yeah, let's scrap my recommendation. Since Team WordPress introduced the password visibility functionality into the login form, I would still like to recommend that Team WordPress develop and publish a constant or filter that will allow its removal. In this case, I feel using a plugin is a band-aid solution. It's a lot easier (and simpler), to say, offer a /wp-config.php constant or filter that could look like this:

Constant:

define('WP_PASSWORD_BUTTON_DISPLAY', false);

Filter:

add_filter( 'wp_pw_button_display', '__return_false' );

They could then be added to the list of constants published here:

Thank you!

Last edited 3 years ago by generosus (previous) (diff)

#4 @johnbillion
3 weeks ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Good discussion points here but it doesn't look like there's anything to be done in core. Cheers!

Note: See TracTickets for help on using tickets.