Overview
The existing username constraint is useful but limitedly effective: A user 'JohnDoe' is not allowed to use 'JohnDoe' as a password, but can simply append a character to circumvent the constraint (e.g., 'JohnDoe1'). Such passwords are vulnerable to cracking. My colleague sephraim and I have implemented a second option to the username constraint to prevent these passwords. When enabled, the password can neither match nor contain the username.

Implementation
The user enters '1' to disallow passwords exactly matching the username. The username enters '2' to disallow passwords containing the username. (The behavior for any other value is unspecified but will be the same as entering '2'). Install code is included to convert any values entered prior to this patch to '1', so the behavior will be unchanged until the policy constraint values are manually changed.

Alternative Approaches
This feature could be implemented as a separate constraint, perhaps constraint_contains_username.inc or constraint_username_containment.inc. I could reroll a patch to do that if preferred. The advantage of combining into constraint_username.inc is it prevents a proliferation of constraints. For example, we may later want to have a constraint based on some measure of string similarity to username too. The disadvantage is the use of different values to choose different behaviors is a bit awkward and adds some complexity to the policy settings page. (This owes to the Constraint API limitation of only having one settings field per constraint.)

Rationale for Release Inclusion
* Needed to prevent weak passwords trivially derived from the username. Anyone who uses the username constraint probably should use this.
* Needed to help comply with many enterprise-wide password policies which disallow passwords based on username.

Your consideration and feedback would be appreciated.

Files: 
CommentFileSizeAuthor
#10 password_policy-username_substring-1666054-10.patch3.55 KBdw317
PASSED: [[SimpleTest]]: [MySQL] 335 pass(es).
[ View ]
#9 password_policy-username_substring-1666054-9.patch3.53 KBdw317
PASSED: [[SimpleTest]]: [MySQL] 335 pass(es).
[ View ]
#6 password_policy-username_substring-1666054-6.patch3.23 KBdw317
PASSED: [[SimpleTest]]: [MySQL] 357 pass(es).
[ View ]
#3 password_policy-username_substring-1666054-3.patch5.11 KBdw317
PASSED: [[SimpleTest]]: [MySQL] 358 pass(es).
[ View ]
#1 password_policy-username_substring-1666054-1.patch5.11 KBdw317
FAILED: [[SimpleTest]]: [MySQL] 357 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new5.11 KB
FAILED: [[SimpleTest]]: [MySQL] 357 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Status:Needs review» Needs work

The last submitted patch, password_policy-username_substring-1666054-1.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new5.11 KB
PASSED: [[SimpleTest]]: [MySQL] 358 pass(es).
[ View ]

Had strpos() parameters reversed.

Status:Needs review» Needs work

Honestly I'm not opposed to reworking how the username constraint works as a whole. You're right, the current implementation doesn't really solve the problem. Mind reworking the patch to simply change the default behavior?

Sure, that would be a simpler solution. My only concern is people might be upset if the behavior of the constraint changes after update without their knowledge. Should we print a brief notice at update for those who have username enabled? (Although, I cannot think of why anyone who uses the username constraint would still want to allow usernames to be substrings of passwords.)

Status:Needs work» Needs review
StatusFileSize
new3.23 KB
PASSED: [[SimpleTest]]: [MySQL] 357 pass(es).
[ View ]

This patch changes the default behavior to disallowing passwords containing the username. A message is shown at update to inform the administrator of the change.

Status:Needs review» Fixed

Committed. I'm going to go ahead and roll out this change as 7.x-1.1, so that we can isolate this behavior change as a new release. Thanks!

http://drupalcode.org/project/password_policy.git/commit/467db3d

Version:7.x-1.x-dev» 6.x-1.x-dev
Status:Fixed» Patch (to be ported)

To keep consistency, we should probably make this change to Drupal 6 as well. Care to make a patch there?

StatusFileSize
new3.53 KB
PASSED: [[SimpleTest]]: [MySQL] 335 pass(es).
[ View ]

Gladly. We have sites still on D6 that use this functionality.

Status:Patch (to be ported)» Needs review
StatusFileSize
new3.55 KB
PASSED: [[SimpleTest]]: [MySQL] 335 pass(es).
[ View ]

Minor text change for consistency with D7 patch.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.