Hide password in setup-config.php

[xmarcos]

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".

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.

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).

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, i don't know how in this world you got that wrong.

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

-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.

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

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=
;-)

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.

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.

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.

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).

Replying to intoxination:

Once that is submitted, a test connection is made.

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

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.

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.

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.

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.

#22443 was marked as a duplicate.

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.

-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.

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

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

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