Make WordPress Core

Opened 16 years ago

Last modified 6 months ago

#3534 reopened enhancement

Hide password in setup-config.php

Reported by: xmarcos's profile xmarcos Owned by: rob1n's profile rob1n
Milestone: Future Release Priority: low
Severity: normal Version: 2.1
Component: Upgrade/Install Keywords: has-patch needs-testing has-testing-info
Focuses: accessibility Cc:

Description

The password field in setup-config.php is set as type="text", so when you install WordPress, the password is visible as you type it. This is not only dangerous if you have someone around but it is also a possible risk if someone gets into that machine later, form fields are remembered by the browser most of the times.

In order to fix this we just need to set the field type as password, type="password".

Attachments (6)

setup-config.diff (444 bytes) - added by xmarcos 16 years ago.
patch.diff (2.2 KB) - added by r0uter 9 years ago.
Changed the input text values to placeholders, so they look tidy. changed password type to password. Added a show password link. JQuery is imported from http-must be fixed
password_show_hide.diff (2.4 KB) - added by wpnook 6 years ago.
Adds show/hide button for password obfuscation
password_show_hide_fix.diff (3.8 KB) - added by wpnook 6 years ago.
Fix for password/show hide diff
password_show_hide_fix.patch (3.7 KB) - added by wpnook 6 years ago.
Removes console log
3534 - PR 2071.gif (214.2 KB) - added by costdev 9 months ago.

Download all attachments as: .zip

Change History (53)

#1 @matt
16 years ago

  • Milestone changed from 2.1 to 2.2
  • Resolution set to wontfix
  • Status changed from new to closed

The reason we don't do this is because the people most likely to use this feature are the least able to view source or something to see the password they typed in and forgot.

The password field is not an access method, it's a setting. We wouldn't hide the title, or the categories, or anything else we feel needs to be accessible and editable by the author.

As for the "if you have someone around" argument, if the person is that paranoid they can always minimize that sidebar box.

#2 @markjaquith
16 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Matt, you seem to be talking about the post password option for blog posts... xmarcos is talking about entering the database password in setup-config.php (your answer might be the same, but I just sensed a Cool Hand Luke moment).

#3 @xmarcos
16 years ago

  • Owner changed from anonymous to ryan
  • Status changed from reopened to new

As markjaquith points, I'm talking about the database password in here, there is a description above and a diff file with the small change.

Last edited 8 months ago by xmarcos (previous) (diff)

#4 @xmarcos
16 years ago

  • Milestone changed from 2.2 to 2.1

#5 @JeremyVisser
16 years ago

-1. I always liked the fact that it shows it.

#6 follow-up: @Nazgul
16 years ago

  • Milestone 2.1 deleted

-1 for the current proposed solution.

If you use a field of type password, you should use a confirmation password field as well, because people can't see their password typos this way.

Also, because this is a enhancment and not a bugfix, I'm pushing it out of scope for 2.1.

#7 follow-up: @foolswisdom
16 years ago

  • Milestone set to 2.2

I like everything to have a milestone or be closed ;-)

#8 in reply to: ↑ 7 ; follow-up: @Nazgul
16 years ago

Replying to foolswisdom:

I like everything to have a milestone or be closed ;-)

What's keeping you:
http://trac.wordpress.org/query?status=new&status=assigned&status=reopened&milestone=
;-)

#9 in reply to: ↑ 8 @foolswisdom
16 years ago

Replying to Nazgul:

What's keeping you:
http://trac.wordpress.org/query?status=new&status=assigned&status=reopened&milestone=
;-)

Slowly but surely, I have been working through those. Many are no longer valid.

#10 in reply to: ↑ 6 ; follow-up: @xmarcos
16 years ago

  • Milestone changed from 2.2 to 2.1

Replying to Nazgul:

-1 for the current proposed solution.

If you use a field of type password, you should use a confirmation password field as well, because people can't see their password typos this way.

Also, because this is a enhancment and not a bugfix, I'm pushing it out of scope for 2.1.

For the third time i think, this is the DATABASE PASSWORD, ok?

You won´t forgot it because you already have it, otherwise you won't get Wordpress running, trust me, no database password, no Wordpress.

Regarding the confirmation, it is NOT A USER-SET PASSWORD. Again you have the password already, if you mistype it, you get and sql connection error.

Now, I remember why I avoid posting tickets, people just don't take the time to read descriptions.

#11 @akbigdog
16 years ago

For what it's worth, I agree that the field *should* be a password field and *should not* have a password confirmation field.

I install WordPress about twice a month, and I don't particularly like seeing all my previous database passwords pop up when the database password field receives focus, especially if I have a client looking over my shoulder.

For the other point, the person installing WP will know immediately whether they typed the password incorrectly or not when they go to the next installation page because WP will tell them it can't connect to the database. I usually just copy and paste anyway. And if people are using the one-click Fantastico installations--as I'm guessing many who would be prone to mistyping a DB password would be--they never see the field, so they can't mess it up with a wrong value.

#12 follow-up: @intoxination
16 years ago

Perhaps the best solution would be to change it to a password field. Once that is submitted, a test connection is made. If it succeeds, the installation proceeds. If it fails then it returns to the previous form alerting the end user of the error (numerous other systems utilize something very similar).

#13 in reply to: ↑ 12 ; follow-up: @foolswisdom
16 years ago

Replying to intoxination:

Once that is submitted, a test connection is made.

That sounds good. Setting milestone to 2.2 awaiting a patch.

#14 @foolswisdom
16 years ago

  • Milestone changed from 2.1 to 2.2

#15 in reply to: ↑ 10 @rob1n
16 years ago

  • Keywords dev-feedback 2nd-opinion added; password setup removed
  • Milestone changed from 2.2 to 2.3

Replying to xmarcos:

Replying to Nazgul:

-1 for the current proposed solution.

If you use a field of type password, you should use a confirmation password field as well, because people can't see their password typos this way.

Also, because this is a enhancment and not a bugfix, I'm pushing it out of scope for 2.1.

For the third time i think, this is the DATABASE PASSWORD, ok?

You won´t forgot it because you already have it, otherwise you won't get Wordpress running, trust me, no database password, no Wordpress.

Regarding the confirmation, it is NOT A USER-SET PASSWORD. Again you have the password already, if you mistype it, you get and sql connection error.

Now, I remember why I avoid posting tickets, people just don't take the time to read descriptions.

Number one, being rude isn't going to get you anywhere. Whatsoever.

Secondly, Nazgul IS referencing the DATABASE password. If it's a passworded field, you can't see what you type in, and thus is more liable to typos. I am -1 for including this. It's not a defect -- it's a feature.

#16 in reply to: ↑ 13 @rob1n
16 years ago

Replying to foolswisdom:

Replying to intoxination:

Once that is submitted, a test connection is made.

That sounds good. Setting milestone to 2.2 awaiting a patch.

It would probably be prudent to set up a second confirmation field, too, then.

#17 @rob1n
16 years ago

  • Milestone changed from 2.3 to 2.2
  • Owner changed from ryan to rob1n
  • Status changed from new to assigned

#18 @MichaelH
16 years ago

Just an observation that two MySQL database creation processes, GoDaddy and cPanel, use different methods. GoDaddy hides the password and requires you to type the password twice. cPanel displays the password and only requires the password once.

#19 @rob1n
16 years ago

  • Keywords dev-feedback 2nd-opinion removed
  • Milestone 2.2 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

I suppose it's up to personal choice. I think we should keep it the way it is right now, as having it in cleartext DOES limit typos (and eliminates, if the user double checks). It's not as though you enter this password in every day, like the user password.

If one of the developers want to change this, please reopen and assign to me, as I will gladly cook up a patch.

#20 @SergeyBiryukov
10 years ago

#22443 was marked as a duplicate.

#21 @empireoflight
10 years ago

It's been years since this was discussed, and I think it warrants discussion. There's something just wrong about legible passwords in text inputs. Make them type it twice.

#22 @rmccue
10 years ago

-1 on changing it. Keeping it as a text field seems like better UX to me. For similar types of interfaces, see the wifi password input interfaces in most OSes, which have a show password checkbox to ensure that you don't mistype it.

#23 @markoheijnen
10 years ago

So +1 for having that checkbox and default hidden ;)

#24 @matt
10 years ago

It's interesting that some modern services are starting to go the other direction:

http://www.lukew.com/ff/entry.asp?1653

#25 @nacin
9 years ago

#25630 was marked as a duplicate.

This ticket was mentioned in IRC in #wordpress-dev by tonythomas. View the logs.


9 years ago

@r0uter
9 years ago

Changed the input text values to placeholders, so they look tidy. changed password type to password. Added a show password link. JQuery is imported from http-must be fixed

#27 @ocean90
8 years ago

#28996 was marked as a duplicate.

#28 follow-up: @amansurov
8 years ago

Let me give you a user's viewpoint: when I installed WP couple hours ago and saw password field to be plaintext, I didn't think for a second it's a feature, just a horrible typo someone made. Now I wonder if at some other place a whole DB access is made as transparent as a password was here. Passwords are expected to be entered into password fields. That is standard behaviour. If you insist on having it plaintext, at least put a memo nearby to explain it to user.
You can verify password with query or put a checkbox to make text visible, what gives user an option to opt-in for a non-standard behaviour

#29 in reply to: ↑ 28 @bi0xid
8 years ago

Replying to amansurov:

You can verify password with query or put a checkbox to make text visible, what gives user an option to opt-in for a non-standard behaviour

+1 for the checkbox to show/hide the password.

#30 @DrewAPicture
8 years ago

  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Related: There has been some discussion over in #24633 about using an "eye" icon or similar concept for revealing passsword fields in the user-edit/profile screen. Maybe something to consider in 4.1 or later.

#31 @wonderboymusic
7 years ago

  • Milestone changed from Awaiting Review to 4.3
  • Resolution set to fixed
  • Status changed from reopened to closed

#32 @ocean90
7 years ago

  • Milestone changed from 4.3 to Awaiting Review
  • Resolution fixed deleted
  • Status changed from closed to reopened

This is about the MySQL password.

#33 @Narthur
7 years ago

+1 for obfuscating input unless an "eye" icon or similar is checked.

Just had a very embarrassing moment installing WordPress while screen sharing with a friend. Muscle memory ensured my password was entirely outputted in plaintext before I even realized what was happening.

An "eye" icon with default obfuscation should make everyone happy.

@wpnook
6 years ago

Adds show/hide button for password obfuscation

#34 @wpnook
6 years ago

  • Keywords has-patch added
  • Resolution set to invalid
  • Status changed from reopened to closed

I just added password_show_hide.diff which hopefully makes everyone happy.

Since the majority of the debate on this issue took place ~9 years ago, many users have argued for a clean show/hide option for displaying the password.

This patch includes internationalization for the aria labels and outputted button text.

I also removed the default value from the password and used a placeholder instead, to avoid obfuscation of the initial "password" value.

#35 @wpnook
6 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

@wpnook
6 years ago

Fix for password/show hide diff

#36 @wpnook
6 years ago

Whoops. My original diff did not include the new setup-config.js file. New patch added.

@wpnook
6 years ago

Removes console log

#37 @mattheweppelsheimer
4 years ago

  • Keywords needs-unit-tests needs-testing added

#38 @markparnell
2 years ago

  • Component changed from General to Upgrade/Install
  • Keywords needs-refresh added
  • Severity changed from minor to normal

I'd love to see this resolved - entering passwords in plain-text should be considered a security issue. Using the same interface that is used elsewhere (a password-type field with a toggle to view the entered text should the user choose to do so) makes the most sense to me. I wasn't able to get the existing patch to apply to trunk though, so marking for refresh.

This ticket was mentioned in PR #2071 on WordPress/wordpress-develop by costdev.


9 months ago

  • Keywords needs-refresh removed

#40 @costdev
9 months ago

  • Focuses accessibility added
  • Keywords has-testing-info added; needs-unit-tests removed
  • Marking as has-testing-info and removing needs-unit-tests as manual testing should suffice.
  • Adding accessibility focus to verify that there are no regressions.

Testing instructions

  • Checkout PR 2071.
  • Build with npm run build or npm run build:dev, depending on your preferred test environment.
  • Rename your wp-config.php file to wp-config.php1.
  • Navigate to /wp-admin/.
  • Click "Continue".
  • Click "Let's go!".
  • The "Password" field should show the "password" placeholder.
  • Type a password into the "Password" field.
  • The password should be masked.
  • Click the "Show" button.
  • The password should be revealed and the "Show" button should now read "Hide".
  • Click the "Hide" button.
  • The password should now be masked again.

Cleanup

  • Delete the newly generated wp-config.php file.
  • Rename your wp-config.php1 file back to wp-config.php.

#41 @costdev
9 months ago

  • Milestone changed from Awaiting Review to 6.0

Milestoning for 6.0.

#42 @Clorith
8 months ago

I noticed this ticket, and it's resolution, being set as the baseline for #9883 as well.

I'd like to make a counter-proposal, these both suggest adding a button outside the input-flow, which in the case of this ticket, even ends up on a newline under the input field, so not properly being attached to its related input area.

Is there any reason we can't use the established pattern introduced to the login screen in [46256], which has a password reveal-toggle that "overlays" the input area, so that a clear connection is kept, and the visual flow isn't broken up?

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


6 months ago

#44 @ryokuhi
6 months ago

We reviewed this ticekt today during the accessibiltiy team's bug-scrub.

The team suggests to first test that @costdev's patch works, and then make a decision about how to make the interfaces consistent, which is also important for accessibility.

This ticket was mentioned in Slack in #core by sabernhardt. View the logs.


6 months ago

This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.


6 months ago

#47 @sabernhardt
6 months ago

  • Milestone changed from 6.0 to Future Release
Note: See TracTickets for help on using tickets.