Password Policies and Drupal

People tend to choose bad passwords if they are allowed to.

By default Drupal provides some guidance about how to "make your password stronger," but there's no enforcement of any particular password policy out of the box. As usual, there's a module for that. More than one in fact.

Thinking on password policies has evolved over the years. The United States National Institute for Standards and Technology (NIST) has been working for some time on a new set of guidelines which are a good basis on which to formulate your own password policy.

The default Drupal 7 password form

Security is always a compromise between mitigating risk and convenience. A fairly recent piece of research on password strategies from Microsoft, for example, suggested that users should use simple memorable passwords for "low-risk" sites, reserving more complex passwords for sites where the risk warrants the higher effort involved. Not everybody will agree with this suggestion, but it illustrates the tradeoff.

In other words, if your site is all about users sharing gifs of their cats, you may choose to make your password policy somewhat more lenient than that for a site where users access sensitive financial or healthcare information.

The NIST guidelines emphasize user-friendliness, and point out that excessively onerous password policies often have negative effects on security in terms of users' behavior. Forcing users to change their passwords every week, for example, is likely to lead to many choosing worse passwords than they would otherwise have done.

We'll now go through the main points of the NIST guidelines and look at how they relate to Drupal. What modules and/or configuration can be used to implement a policy based on these guidelines?

Size: Minimum 8 characters, maximum length of at least 64

Drupal password policy allows you to set a minimum length for all passwords.

As (any current version of) Drupal does salting and hashing of passwords, there's effectively no constraint on the maximum length imposed by storage in the database. However, there are practical limits imposed by the Form API. The password form input will typically have a maxlength of 128 characters (based on the database schema, although as noted it's not the cleartext password which will go into the database).

It's possible to set passwords longer than 128 characters (e.g. with drush) but users won't actually be able to submit these passwords through Drupal's forms to login. It would also be possible to increase that 128-character limit imposed by the combination of the database schema and the Form API, if that was a strict requirement.

Composition:

Do allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji. Do not prescribe composition rules (e.g at least 2 of numbers, lower and upper case etc.)

Drupal has had fairly decent Unicode support for a long time (e.g. https://www.drupal.org/node/26688), but support for most emojis (and multi-byte UTF-8 in general) in the database came relatively late in the Drupal 7 development cycle, and often requires some tweaking of the database settings (see: https://www.drupal.org/node/2754539). However, as a salted hash rather than the password itself is stored in the database, passwords with emojis and other unicode characters typically work fine in Drupal even without the database support. Depending on how your PHP is set up (e.g. whether you have the mbstring extension), it may be worth testing this.

The Password Policy module allows quite complex composition rules to be set up for passwords, but the NIST guidelines reflect substantial research which suggests these often do more harm than good.

The Password Strength module "provides realistic password strength measurement and server-side enforcement," which is a user-friendly alternative to prescriptive composition rules.

The NIST guidelines suggest that spaces are allowed in passwords, which arguably makes for more user friendly policies when it comes to pass phrases. Drupal will allow spaces in passwords out-of-the-box.

Screen for known bad passwords

The Drupal 7 version of Password Policy module has (fairly simple) support for a blacklist rule. This blacklist can be populated with a dictionary of known-bad passwords, for example this list of the 500 worst passwords, or many alternatives. See the Openwall wordlists collection for more details.

Blacklist functionality is being worked on for the Drupal 8 version: https://www.drupal.org/node/2678578

Correct Horse Battery Staple

Credit: xkcd.com

This is a relatively complex subject. Although very simple phrases based on only a few dictionary words may not make great passwords (See: Bad Passwords Are Not Fun and Cracking The 12+ Character Password Barrier, Literally ), it's perfectly possible to create good high entropy passwords using only dictionary words (See The Diceware Passphrase Home Page ), especially given a sufficiently high maximum password length.

The dictionary checking/blacklisting capabilities of the Password Policy module are fairly basic. It would almost certainly not be a good idea to use it to check passwords against a wordlist of ordinary dictionary words.

Avoid using hints or reminders

Drupal doesn't implement passwords hints or security questions out-of-the-box. There are contrib modules such as: Security Questions.

However the NIST guidelines recommend against using using these. There are many recent examples where security questions with fairly easy to guess or research answers have been used to compromise user accounts.

Although not strictly the same issue: Username Enumeration Prevention is worth a mention here. It aims to make it more difficult for potential attackers to find usernames which they can then use to attempt to login.

Use TFA / MFA

Two Factor or Multi Factor Authentication is an effective way to prevent unauthorised logins in the event of credential compromise or successful brute force attack.

Combining something you know ( password ) with something you have ( TFA/MFA token ) greatly reduces the risk of unauthorized access.

Drupal has a mature Two-factor Authentication (TFA) module available.

Plugins are available to integrate this with various libraries and services, such as Google Authenticator and SMS providers (e.g. Twilio).

A Drupal 8 version of this module is being worked on (details on the project page).

Implement rate-limiting

This is important for guarding against brute force attacks.

Drupal does rate-limiting out of the box, referred to internally as 'flood control'. However, there's not really any UI which exposes the configurations that can be tweaked. See: Flood control.

You don't need the UI module to change these configurations, but it's useful to show you the defaults and what Drupal variables governing the flood control settings you can change (perhaps looking at the screenshot of its admin form is sufficient). A Drupal 8 version of this module is being worked on (details on the project page).

There are modules which allow you to take rate limiting further, for example: Login Security.

There are also modules which integrate with firewall-level blocking of sources of potentially malicious requests, for example: Fail2ban Firewall Integration

Other considerations

Both Yahoo! and Google have recently done some work around doing away with passwords completely. There's a module for that: Passwordless.

Some sites have decided - for dubious reasons - to disallow pasting from the clipboard into password fields. This obstructs the use of password managers, and arguably goes against the NIST recommendations of being user friendly.

Developers should avoid using bad passwords when sites are being built on the assumption that somebody will replace them with proper passwords before go live. When handing sites over or setting users up for the first time, make use of Drupal's one-time login link functionality (for example via the drush uli command).

Conclusion

Drupal's user password system is fairly capable out of the box but - as usual - there are contrib modules which enhance the functionality and allow additional options and configurations. The Drupal 8 version of the Password Policy module uses the plugin system, meaning other modules can extend the base functionality. The Password Strength module works this way in Drupal 8, for example.

NIST's guidelines emphasise user-friendliness when it comes to password policies. Some of the more prescriptive approaches can be argued to do more harm than good when it comes to encouraging users to select good passwords.

In general, password policies should try to avoid users selecting very poor passwords, but, just as important, sites should not get in the way of users trying to employ high entropy "secure" passwords.