As a user attempting to login, when I get my password incorrect a number of times, my status becomes blocked, and Drupal does not then send password reset emails.

[govcms]

As a user attempting to login, when I get my password incorrect a number of times, my status becomes blocked, and Drupal does not then send password reset emails.

[invisigoth]

Login Security module has been employed by GovCMS to block users after x failed login attempts and Drupal does not perform certain operations for a blocked user.

from login_security.module:

function login_user_block_user_name($variables) {
...
      user_save($account, array('status' => 0), NULL);
...
}

[fiasco]

• Is Drupal talking to an SMTP server to send the email?
• Is the email just not reaching the user's inbox (seen as spam)?
• Or; Is Drupal actually not sending the mail at all?

[invisigoth]

Different from Drupal core's default behaviour, GovCMS does not send password reset emails to blocked users at all. This is due to its employment of the "username enumeration prevention" module that does not load blocked users. See username_enumeration_prevention.module:

$users = user_load_multiple(array(), array('name' => $name, 'status' => '1'));

Although this will print the message "Further instructions have been sent to your e-mail address." to the screen, no password reset emails are actually sent for blocked users.

Combined with the behaviour of the login security module, it leads to the reported issue.

[pandaskii]

The "username_enumeration_prevention" module is featured in Acquia Insight security section, and seems that this module intentionally disallow blocked users reset emails.

[fiasco]

So what should the actions be after X number of failed login attempts? I imagine there is something we can do here with Rules module to either notify someone or reset their login attempts.

[invisigoth]

The user module in Drupal core implements flood control, which prohibits a user from authenticating for a set duration. Whatever the solution is, it may need to meet the relevant requirements set by the 2015 Australian Government Information Security Manual.

It seems the most straightforward solution, by just using the features provided by Drupal core and still meet the ISM requirements, is to set the two system variables:

• user_failed_login_user_window to 3.154e+8 (10 years)
• user_failed_login_user_limit to 5 (default 5)

The "login security" and "flood control" modules can also be disabled/removed.

[fiasco]

Just a note here, if we move towards this approach (sounds like we will) - we should include the variable_set calls for these variables in an update hook so that distro users are not broken from this change.

We may also want to consider staggering the rollout so that release A disables the modules uninstalls them and the following release B removes them from the codebase completely.

Removing modules from the distro is hard as it prevents users from skipping versions of govCMS, they have to literally upgrade through each release incrementally.

[fiasco]

@Malone has done a pull request (#50) where he removed a module. He says that careful attention is required about this approach because of how it impacts distro users.

[xtfer]

Control 0430 in the ISM states that users must be blocked after 5 attempts, and that the reset function should be admin only. If an administrator selects the "Force password reset" for a user, it should send the reset email, even if the user is blocked.

Making the user reset window 10 years has the unfortunate side effect of logging the user out after five failed login ever, rather than just five sequential logins, and would seem to be entirely unrelated to the problem at hand.

I suggest changing the message to requesting an administrator to unblock them.

[aleayr]

@xtfer, as far I am aware, 0430 has been redefined as of the 2015 controls, and no longer explicitly requires an administrator to reset the password.

Control 1403 has been added in its place, and the section on Resetting passphrases (Controls 0976 and 1227) should be our guide for implementing this.

[xtfer]

I'll take your word for it. It's very hard to get a changelist for those controls unless you are a government employee, so I hadn't realised it had changed.

The change to the reset window is probably still undesirable, in any case.

[aleayr]

Definitely a good point RE the reset window, and thanks for raising it as an issue!

@invisigoth @jozhao Thoughts about the 10 year flood window issue? As @xtfer points out, that will result in 5 incorrect password attempts at any time in that 10 years causing a block. Essentially, a successful password login should reset that counter?

[invisigoth]

@aleayr a successful login with correct user name and password will clear the logged flooding attempts in the flood table.

As an example, the following scenario will NOT result in a user account being "blocked"

Fail --- Fail --- Fail --- Successful --- Fail --- Fail --- Fail --- Fail --- Successful

However I suggest further tests to determine if Drupal core's flood control function is truly sufficient to meet all requirements set by the latest ISM.

[nathan-w]

@fiasco @aleayr keen to hear thoughts on next steps for this - and keen to progress it

[fiasco]

I think a good next step would be to produce some behat tests that verify our assumptions on how govCMS responds around authentication attempts. Based on the outcomes of those tests we can determine what should be failing/passing and adjust accordingly.

[aleayr]

This has been fixed via #194.