Make WordPress Core

Opened 15 years ago

Closed 11 years ago

Last modified 11 years ago

#2870 closed enhancement (fixed)

Make installation form pluggable (was: allow user to set password)

Reported by: markjaquith Owned by: garyc40
Milestone: 3.1 Priority: normal
Severity: normal Version: 2.0.4
Component: Upgrade/Install Keywords:
Focuses: Cc:


There are a few things about WordPress' handling of passwords that annoy me.

==Default Password==

When WordPress is installed, a random password is created. It would be nice if the user, upon logging in for the first time, was prompted to set their own password.

==Password Reset==

Resetting a password takes too many steps. There are two e-mail verification steps, when one would do. Once the initial verification link is clicked, the user should be provided with the new password (on the page, not just in an e-mail.) They also could be provided with a "set your password" form allowing them to set the password to something they'll remember, so they're not doing this again the next time they want to blog from the library.

Attachments (3)

install.php.diff (4.0 KB) - added by darkfate 15 years ago.
allow user the select username and password
wp-login.php.diff (5.0 KB) - added by darkfate 15 years ago.
allow user to reset password with one form, updated: took out second mail with password
2870.patch (3.3 KB) - added by pishmishy 14 years ago.
Makes installation form pluggable

Download all attachments as: .zip

Change History (48)

#1 @darkfate
15 years ago

Instead of asking the password on install, why not put it in the form when you install. No sense having an extra redirect.

#2 @darkfate
15 years ago

oops. I meant instead of asking the password AFTER install.

#3 @darkfate
15 years ago

  • Keywords bg|needs-patch added

#4 @darkfate
15 years ago

  • Milestone set to 2.0.4
  • Version changed from 2.1 to 2.0.3

#5 @darkfate
15 years ago

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

I don't think we should allow the user to make his/her password by default since it can be insecure. See #2910 which encompasses both username and password.

#6 @darkfate
15 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I guess I'll just leave it open to discussion.

#7 @masquerade
15 years ago

I don't think we should allow the user to make his/her password by default since it can be insecure.

This is the worst argument I've heard for not including this feature over the years. If a user wants a dumb password, they will go in and place a dumb password. Set a secure default all you want, but a stupid user will go in and use their stupid password regardless of what you set.

#8 @tenpura
15 years ago

WP does not have these common password checking function, does it? It will improve the security of WP a bit.

  • a password should be different from its login name (admin:admin is no good)
  • a password should be long enough (at least 5 or 6 characters long?)

#9 @Viper007Bond
15 years ago

+1 for allowing picking of username/password during install. I hate having to go in and change the login of the original "admin" account after installing WP.

#10 @darkfate
15 years ago

I'll use the patch that I made for #2910 and add a password input field. The password reset will be a different patch. Anyone want to do that patch?

15 years ago

allow user the select username and password

#11 @darkfate
15 years ago

I need some to test those patches. The reset password still sends two emails. The second email just sends what your new password is. Just so you can keep it in your email. You put your new password in the same lost password form, then it sends the verification link. That verification link leads to the page which tells you that you your new pas (that you set). I guess the second email isn't nescarry because the user set their own password, but I'll leave that up to everyone else.

#12 @masquerade
15 years ago

-1 on passwords being sent plaintext in email at all.

15 years ago

allow user to reset password with one form, updated: took out second mail with password

#13 @darkfate
15 years ago

  • Keywords bg|has-patch|needs-testing|2nd-opinion added; bg|needs-patch removed

#14 @darkfate
15 years ago

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

#15 @darkfate
15 years ago

  • Status changed from new to assigned

#16 follow-up: @matt
15 years ago

  • Milestone changed from 2.0.4 to 2.1

Passwords are sent in email (and should continue to be) because that's how people look them up and save details of different accounts.

#17 @markjaquith
15 years ago

Is there any reason that the password can't be (additionally) provided in the browser after clicking the confirmation link? At that point, your ownership of the e-mail account is assured, so why force them to check their e-mail again?

#18 @darkfate
15 years ago

That's what my patch does. Once you click the confirmation link, it shows you your new password in the browser. I also agree with masquerade when he says that sending emails with a plain text password is risky. The whole point of setting your own password is so that you don't forget it. You shouldn't need to keep an email reminder. With the patch I made, it's a lot easier to make a new password if you need to.

#19 @masquerade
15 years ago

Out of curiosity on a comparison of how many other web applications do this, I searched my primary inbox for the past couple of years, a few thousand mails, including everything I ever signed up for, for my passwords. 9 results came up total, which I know is tiny compared to how many places I have signed up for. A few offenders are dreamhost, newegg, and a few other places I buy hosting from. Nothing from any forum, blogging site, etc.

Really, to me, encouraging users to save their password in their inbox is encouraging more and more lenient security policies. I'm not saying that some fool might do it anyways, but we shouldn't facilitate people trying to do something foolish, and anything that shows you the password you just created is included. You should have to type it twice to confirm you know the password, we shouldn't have to tell them what they just typed twice, I'm pretty sure they know what they just put.

#20 @darkfate
15 years ago

So, can this be commited to the trunk? Or should more testing be done.

#21 @darkfate
15 years ago

Hmm. So is this going to make it into the 2.1 release. Or is this for the 2.2 release?

#22 @darkfate
15 years ago

  • Version changed from 2.0.3 to 2.0.4

#23 @markjaquith
15 years ago

Reinstate the second e-mail with the password (in addition to showing it in the browser), and this is +1 for me.

#24 @matt
15 years ago

  • Milestone changed from 2.1 to 2.2

#25 @foolswisdom
15 years ago

  • Keywords developer-feedback added; bg|has-patch|needs-testing|2nd-opinion removed
  • Milestone changed from 2.2 to 2.3

#26 @foolswisdom
14 years ago

  • Milestone changed from 2.3 to 2.5 (future)

#27 @pishmishy
14 years ago

  • Owner changed from darkfate to pishmishy
  • Status changed from assigned to new

I hope no one minds me taking ownership. I've got some ideas for this ticket that I'd like to work on.

14 years ago

Makes installation form pluggable

#28 @pishmishy
14 years ago

  • Keywords has-patch added

The patch I've just attached allows you to easily add new input elements to the installation form. wp_install is already pluggable and can be changed to make use of any new inputs if necessary.

Using my patch, a password box for the installation can be added in a few lines of code. Suggest that the password reset aspect of this ticket is separated to another ticket.

#29 @pishmishy
14 years ago

  • Status changed from new to assigned
  • Summary changed from Password handling improvements to Make installation form pluggable (was: allow user to set password)

Created #5919 for Password Reset Aspects. Renaming accordingly

#30 @pishmishy
14 years ago

Note: wp-content/install.php is the place to overwrite wp_install()

#31 @Denis-de-Bernardy
13 years ago

  • Keywords dev-feedback added; developer-feedback removed

#32 @darkfate
13 years ago

I like this idea. I can't believe I did that three years ago. The hooks are a better idea though.

#33 @neoxx
12 years ago

-1 for sending any passwords (except temporary ones) in plaintext via e-mail. - if one forgets his password, he can use the password lost function.

#34 @neoxx
12 years ago

another thought: why not sending an activation-code instead of the password itself? besides the increased security, this would also verify a newly registered e-mail address and therefore keep most of the spam-registrations out...

#35 @Denis-de-Bernardy
12 years ago

  • Component changed from Administration to Upgrade/Install

#36 @Denis-de-Bernardy
12 years ago

  • Keywords needs-patch added; dev-feedback has-patch removed
  • Milestone changed from 2.9 to Future Release

#37 @hakre
12 years ago

on wishlist30 for neoxx

#38 @hakre
12 years ago

Related: #10006

#39 in reply to: ↑ 16 @neoxx
11 years ago

Replying to matt:

Passwords are sent in email (and should continue to be) because that's how people look them up and save details of different accounts.

While writing a post about my last five years WordPress, I came across this Wikipedia-article http://en.wikipedia.org/wiki/Password#Procedures_for_changing_passwords

In the last four years (since Matt's comment) a lot has changed and maybe we should re-think this sending of plain-text-password-emails.

Instead, upon verification of the email-address we could make use of the password strength meter or assign a random password. Anyway, if the user forgets the password, we already got the handy mail-function to request a password reset...

#40 @RyanMurphy
11 years ago

Does the Password Reset part fit into the scope for 3.1?

The Default Password part no longer applies, since the user is able to set it when they install WordPress, and users created after it is installed get the nag notice.

#41 @hakre
11 years ago

Related: #14943

#42 @garyc40
11 years ago

  • Owner changed from pishmishy to garyc40

#43 @johnbillion
11 years ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from accepted to closed

The simplified password reset functionality introduced in 3.1 means both points raised in this ticket have been addressed.

#44 @dd32
11 years ago

  • Milestone changed from Future Release to 3.1

Marking as 3.1 based on johnbillion's comment.

#45 @hakre
11 years ago

Related: #16911

Note: See TracTickets for help on using tickets.