Make WordPress Core

Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#6146 closed defect (bug) (fixed)

wp_generate_password() fails the password strength meter

Reported by: tellyworth's profile tellyworth Owned by: pishmishy's profile pishmishy
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.5
Component: General Keywords: has-patch
Focuses: Cc:

Description

The text below the password strength meter says "Use upper and lower case characters, numbers and symbols like !"?$%&( in your password." But the passwords returned by wp_generate_password() don't do that - in fact they aren't measured as "strong" by the meter, just "good".

The enclosed patch increases the length of generated passwords, and includes symbols in the character set. It also allows the length to be specified with a parameter. Passwords generated after the patch are almost always considered strong by the strength meter.

Regardless of whether or not the increased length is accepted, I think it'd be a good idea for wp_generate_password() to accept a length parameter.

Attachments (1)

strong-passwords-r7206.patch (726 bytes) - added by tellyworth 16 years ago.

Download all attachments as: .zip

Change History (10)

#1 @lloydbudd
16 years ago

  • Milestone changed from 2.6 to 2.5
  • Version set to 2.5

#2 @pishmishy
16 years ago

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

#3 @pishmishy
16 years ago

  • Milestone changed from 2.5 to 2.6

The function is designed to be pluggable. I'm not sure there's a need for a length parameter as long as we keep password generation consistent across WordPress. It's easier to change the length consistently at a later stage by editing the function (or replacing it with a plugin) rather than changing every call.

I left the symbols out to keep things simple for users. I was even considering removing more characters so confusion between similar characters such as "1Il" couldn't occur (as with the previous password generation function).

I'm bumping the milestone up - not because I disagree with the idea of changes - but because I think the compromise between password usability and complexity needs more discussion first.

#4 @tellyworth
16 years ago

  • Milestone changed from 2.6 to 2.5

pishmishy: I'd support removing symbols and similar characters from password generation - point is that the passwords generated by WordPress should be considered "strong" by the strength meter. (The strength meter probably needs improving too, I fixed the easy side of the equation here).

The length parameter is optional with a default value. Callers that don't care about the length will leave that out, so the default can be changed globally later on. This function is the API blueprint for pluggable versions; I think that for callers that do care about the length, the API ought to accept it as an optional parameter. The function is new in 2.5 so for long term support I think it'd be worth doing now. I've bumped the milestone back down to 2.5 to encourage discussion of that.

#5 @pishmishy
16 years ago

Can you give an example where someone might want to use different length passwords in different sections?

I'm not that huge a fan of the stength function either, it's a bit fluffy =)

#6 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [7796]) Add length arg to wp_generate_password() and lengthen secret. Props tellyworth. fixes #6146 for trunk

#7 @ryan
16 years ago

(In [7798]) Add length arg to wp_generate_password() and lengthen secret. Props tellyworth. fixes #6146 for 2.5

#8 @ryan
16 years ago

(In [7802]) strlen - 1. Props mdawaffe. see #6146

#9 @ryan
16 years ago

(In [7803]) strlen - 1. Props mdawaffe. see #6146

Note: See TracTickets for help on using tickets.