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.
Comments
Comment #1
dw317 CreditAttribution: dw317 commentedComment #3
dw317 CreditAttribution: dw317 commentedHad strpos() parameters reversed.
Comment #4
erikwebb CreditAttribution: erikwebb commentedHonestly 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?
Comment #5
dw317 CreditAttribution: dw317 commentedSure, 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.)
Comment #6
dw317 CreditAttribution: dw317 commentedThis patch changes the default behavior to disallowing passwords containing the username. A message is shown at update to inform the administrator of the change.
Comment #7
erikwebb CreditAttribution: erikwebb commentedCommitted. 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
Comment #8
erikwebb CreditAttribution: erikwebb commentedTo keep consistency, we should probably make this change to Drupal 6 as well. Care to make a patch there?
Comment #9
dw317 CreditAttribution: dw317 commentedGladly. We have sites still on D6 that use this functionality.
Comment #10
dw317 CreditAttribution: dw317 commentedMinor text change for consistency with D7 patch.
Comment #11
erikwebb CreditAttribution: erikwebb commentedhttp://drupalcode.org/project/password_policy.git/commit/b84d90f