I work at a federal agency that has recently implemented a strong password policy requiring that users First or Last Names can not be included as a substring of the password. To implement this, we have added First Name and Last Name as fields in our D7 sites. We also use Password Policy. To extend the functionality of Password Policy, it would be great to add Custom User Fields as a checkbox list that includes any Text fields available from the User entity and to exclude these from the Password using strpos comparison similar to the current constraint_username. This would provide flexibility for users to assign this on a Policy by Policy basis, though for the moment First and Last name are the most likely use case.

Comments

aohrvetpv’s picture

Hello, we also needed to disallow first name and last name within the password for a website I work on, so we implemented a custom constraint for 7.x-1.x just for first and last name fields. In this comment I will share the code for that constraint in case it might be of use to you or anyone else. In the next comment I will address your general feature request.

Maybe you have already implemented this constraint too. I am not sure whether your screenshot is a mock-up or an implementation.

Installation:
1. Apply patch.
2. Edit constraints/constraint_real_name.inc and change instances of field names as needed. (Our field names are simply field_first_name and field_last_name.)
3. Set positive number in policy for the constraint.

Warnings:
- This has been minimally tested and has no automated tests. It should not be used in production without review/testing.
- It is a bit dangerous to add custom constraints by copying them into the constraints directory, because whenever the Password Policy module is updated they may be removed. That is, you may need to copy the constraint file back into the constraints directory after every update.

aohrvetpv’s picture

To extend the functionality of Password Policy, it would be great to add Custom User Fields as a checkbox list that includes any Text fields available from the User entity and to exclude these from the Password using strpos comparison similar to the current constraint_username. This would provide flexibility for users to assign this on a Policy by Policy basis, though for the moment First and Last name are the most likely use case.

Good suggestion. I think this should actually be possible using tokens with the patch in #1603210: Add token support to blacklist constraint, but I have not tested it. I believe there are tokens available for each field, so you could blacklist passwords containing the first and last name field tokens. Tokens seem like they may be an even more general way to implement this than providing a list of all fields from which to select. Do you think this approach might work?

A potential problem is the token values may not be available until after the fields are saved, which may be a problem if the user sets the password and the field values on the same page (i.e., in the same request).

It would be very helpful to get some testing of the patch in that issue, if you or anyone has the opportunity. I hope to eventually get the blacklist constraint with tokens support ported from 7.x-2.x to 7.x-1.x.

nancydru’s picture

I have some sites where the first/last names fields are part of the User object, and others where they are in the Profile2 object. These are government sites, so I need to be able to access those fields in either object.

nancydru’s picture

I am working on a 7.x-2.x version of this.

Two quick questions:

  1. Where are the $_POST values set?
  2. How do I get the vertical tab comments to change?
aohrvetpv’s picture

I am working on a 7.x-2.x version of this.

Have you looked at #1603210: Add token support to blacklist constraint? Using user fields as password constraints should be possible using that patch, by using User module tokens. I don't know about Profile2.

Where are the $_POST values set?

JavaScript in password_policy.js repeatedly POSTs the candidate password to password_policy/check as it is typed. That path invokes the PHP callback password_policy_ajax_check().

(The $_POST variable values are automatically set by PHP when it receives the POST request.)

nancydru’s picture

I'll take a look at that other issue.

aohrvetpv’s picture

How do I get the vertical tab comments to change?

Can you give an example of what is meant by vertical tab "comment"?

I think the answer is probably by editing password_policy.js, but I'm not completely sure to what text you're referring.

nancydru’s picture

StatusFileSize
new21.49 KB

See image.

nancydru’s picture

Yes, #1603210: Add token support to blacklist constraint seems to handle this request. I would suggest closing it as a duplicate.

I am adding a bit to that issue.

aohrvetpv’s picture

Status: Active » Closed (duplicate)
brooke_heaton’s picture

Blacklist won't work for my situation. Users need to be able to read the message pertaining to user fields so that they are aware of the policy. Blacklist + tokens is a workaround but not a very good one for this use case. Users should see a warning that they cannot, for instance, use their 'First Name' or 'Last Name'. A blanket message that certain unknown words are blacklisted is not helpful.

brooke_heaton’s picture

StatusFileSize
new11.93 KB

This patch adds support for any instances of user fields added via /admin/config/people/accounts/fields (e.g. 'field_first_name', 'field_last_name'). The patch allows textfields that are user fields to be validated via substring position function (if result, password fails). This patch will warn users if they attempt to include the user field string in their password with an explicit message.

Installation:
1. Apply patch.
2. Add a user field at /admin/config/people/accounts/fields (must be a textfield)
3. Select the fields to compare to password at /admin/config/people/password_policy/list/[policy]

Warnings:
- This has been minimally tested and has no automated tests. It should not be used in production without review/testing.

brooke_heaton’s picture

Status: Closed (duplicate) » Patch (to be ported)

Patch created for user fields.

brooke_heaton’s picture

Issue summary: View changes
brooke_heaton’s picture

StatusFileSize
new14.76 KB

Updated patch as #12 did not correctly handle multiple user fields.

brooke_heaton’s picture

brooke_heaton’s picture

StatusFileSize
new130.88 KB

2. How do I get the vertical tab comments to change?

These are targeted in password_policy.js via the id of the subform for the fieldset from the .inc file.

e.g:

$sub_form['user_fields_fieldset'] = array(
        '#type' => 'fieldset',
        '#title' => t('User Fields'),
    );

In patch #15 I do this via the following - this is modeled after the Roles configuration, which also uses a checkbox list:

$('fieldset#edit-user-fields-fieldset', context).drupalSetSummary(function (context) {
      var vals = [];
      $('input[type="checkbox"]:checked', context).each(function () {
        vals.push(Drupal.t('Must not include ') + $.trim($(this).next('label').text()));
        });
      if (!vals.length) {
        vals.push(Drupal.t('Not restricted'));
      }
        return vals.join('<br />');
      });

}

brooke_heaton’s picture

StatusFileSize
new1.83 KB

Updated patch add-constraint-custom-user-fields-2472491-18.patch - previous patch was created with PHP Storm - my bad.

brooke_heaton’s picture

brooke_heaton’s picture

StatusFileSize
new4.34 KB

Uploading latest patch for testing against 7.x-2.x-dev add-constraint-custom-user-fields-2472491-19.patch

brooke_heaton’s picture

StatusFileSize
new312 KB

Updating patch to account or error message when no user fields are selected -this prevents an odd message with blank translatable fields like 'Password must not contain user @user_fields' which was happening when no user fields were selected.

aohrvetpv’s picture

Brooke, I think something went haywire with that last patch.