Extend and customize Drupal functionality with contributed modules.
If a module doesn't quite do what you want it to do, if you find a bug or have a suggestion, then join forces and help the module maintainer. Or, share your own by starting a new module.
A CAPTCHA is a challenge-response test most often placed within web forms to determine whether the user is human. The purpose of CAPTCHA is to block form submissions by spambots, which are automated scripts that post spam content everywhere they can. The CAPTCHA module provides this feature to virtually any user facing web form on a Drupal site.
We do this our spare time, which is unfortunately almost nonexistent at the moment due to real life obligations. To give the CAPTCHA module the required level of maintenance, an extra co-maintainer would be welcome. If you're interested in helping with this very popular module, please contact me or open an issue in the CAPTCHA module issue tracker.
This module provides a way to enforce restrictions on user passwords by defining password policies.
A password policy can be defined with a set of constraints which must be met before a user password change will be accepted. Each constraint has a parameter allowing for the minimum number of valid conditions which must be met before the constraint is satisfied.
The ACL module, short for Access Control Lists, is an API for other modules to create lists of users and give them access to nodes. It has no UI of its own and will not do anything by itself; install this module only if some other module tells you to.
We're aware of the following modules using ACL (let us know if you know of others):
Content Access (optionally uses ACL to provide by-user access control)
The Lightweight Directory Access Protocol (LDAP) project provides integration with LDAP for authentication, user provisioning, authorization, feeds, and views. It also provides apis and building blocks (query and server configuration storage) for other modules.
For sites that are available via both HTTP and HTTPS, Secure Login module ensures that the user login and other forms are submitted securely via HTTPS, thus preventing passwords and other private user data from being transmitted in the clear. Secure Login module locks down not just the user/login page but also any page containing the user login block, and any other forms that you configure to be secured.
The purpose of Spamicide is to prevent spam submission to any form on your Drupal web site. Spamicide adds an input field to each form then hides it with css, when spam bots fill in the field the form is discarded. The field, and matching .css file, are named in such a way as to not let on that it is a spam defeating device, and can be set by admins to almost anything they like(machine readable please). If logging is set, the log will show if and when a particular form has been compromised, and the admin can change the form's field name (and corresponding .css file) to something else.
This module allows site builders to set up fine-grained permissions for allowing "sub-admin" users to edit and delete other users — more specific than Drupal Core's all-or-nothing 'administer users' permission. It also provides and enforces a 'create users' permission.
See the README.txt file for a full explanation of the permissions.
Version 2 of the module was sponsored by AlbanyWeb.
By default Drupal is very secure (especially Drupal 7). However, there is a way to exploit the system by using a technique called username enumeration. Both Drupal 6 and 7 have this issue, but it is much worse for people using Drupal 6. This is because Drupal 6 does not have any built in brute force prevention. When an attacker knows a username they can start a brute force attack to gain access with that user. To help prevent this, it is best if usernames on the system are not easy to find out.
Attackers can easily find usernames that exist by using the forgot password form and a technique called “username enumeration”. The attacker can enter a username that does not exist and they will get a response from Drupal saying so. All the attacker needs to do is keep trying usernames on this form until they find a valid user.
This module will stop this from happening. When the module is enabled, the error message will be replaced for the same message as a valid user and they will be redirected back to the login form. If the user does not exist, no password reset email will be sent, but the attacker will not know this is the case.
This module integrates Drupal with SimpleSAMLphp, the most robust and complete implementation of SAML in PHP. It makes it possible for Drupal to communicate with SAML or Shibboleth identity providers (IdP) for authenticating users. The resulting Drupal site can effectively act as a SAML or Shibboleth service provider (SP).
SimpleSAMLphp - you must have SimpleSAMLphp version 1.6 or newer installed and configured to operate as a service provider (SP).
NOTE: Your SimpleSAMLphp SP must be configured to use something other than "phpsession" (the default) for session storage. The alternatives are memcache or sql. The sql option was added in SimpleSAMLphp version 1.7. The simplest solution for folks running SimpleSAMLphp version 1.7 or higher is to edit the SimpleSAMLphp config/config.php by setting store.type => 'sql' and 'store.sql.dsn' => 'sqlite:/path/to/sqlitedatabase.sq3'
Just-in-time provisioning of Drupal user accounts based on SAML attributes (configurable).
Automatic role assignment based on SAML attributes (configurable).
Dual mode - support for traditional Drupal accounts and SAML-authenticated accounts at the same time (configurable).
The Paranoia module attempts to identify all the places that a user can evaluate PHP via Drupal's web interface and then block those. It reduces the potential impact of an attacker gaining elevated permission on a Drupal site.
Since Drupal 7 is more restrictive in allowing multiple failed logins, using different names (in 6.x version) is not needed any longer. These are the features of 7.x version.
User one account is protected from viewing and editing. Users -- even with 'Administer users' permission -- will be denied access.
User one account is hidden from user listing page, admin/people.
User one account is hidden from user lists such as in blocks, Who's New and Who's Online. User One provides its own version of Who's Online block for correct count of logged in users besides hiding user one.
User One exposes Drupal's built-in values to change otherwise inaccessible such as number of allowed login attempts and time window to remember such login attempts.
While Drupal temporarily deny login after multiple failed logins, User One goes one step further to allow permanently block such IPs automatically and notify the site admin.
Encrypt is a Drupal module that provides an application programming interface (API) for performing two-way data encryption. It allows modules to encrypt data such that it can be decrypted using the same key that was used to encrypt the data. This is useful for storing sensitive information. This module is an API that other modules can use to encrypt data. It doesn't provide any user-facing features of its own, aside from administration pages to manage configuration.
Second-factor authentication for Drupal sites. Drupal provides authentication via something you know -- a username and password while TFA module adds a second step of authentication with a check for something you have -- such as a code sent to (or generated by) your mobile phone.