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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dw317’s picture

Status: Active » Needs review
FileSize
5.11 KB

Status: Needs review » Needs work

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

dw317’s picture

Status: Needs work » Needs review
FileSize
5.11 KB

Had strpos() parameters reversed.

erikwebb’s picture

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?

dw317’s picture

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

dw317’s picture

Status: Needs work » Needs review
FileSize
3.23 KB

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.

erikwebb’s picture

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

erikwebb’s picture

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?

dw317’s picture

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

dw317’s picture

Status: Patch (to be ported) » Needs review
FileSize
3.55 KB

Minor text change for consistency with D7 patch.

erikwebb’s picture

Status: Fixed » Closed (fixed)

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