Login Security
Enhances Drupal login form security by detecting brute-force attacks and implementing configurable blocking protections for users and IP addresses.
login_security
Install
composer require 'drupal/login_security:^2.0'
Overview
Login Security improves the security options in the login operation of a Drupal site. By default, Drupal has only basic access control denying IP access to the full content of the site. This module allows administrators to add multiple layers of access control features to the login forms (default login form at /user and the login form block).
The module tracks failed login attempts and can take various protective actions based on configurable thresholds: temporarily blocking form submissions (soft block), permanently blocking IP addresses using the Ban module (hard block), blocking user accounts, and detecting ongoing password-guessing attacks with email notifications.
All protections operate within a configurable time window (track time), and administrators can customize all user-facing messages with dynamic placeholders for personalized notifications.
Features
- Ongoing attack detection with configurable thresholds and email notifications to administrators when suspicious login activity is detected
- Soft IP blocking that temporarily prevents login form submission while allowing site browsing, automatically expiring after the tracking time window
- Hard IP blocking that permanently bans IP addresses from the entire site using Drupal core's Ban module, requiring manual removal
- User account blocking after configurable failed login attempts, preventing login regardless of the source IP address
- Customizable messages with dynamic placeholders (username, IP, site name, attempt counts, etc.) for all blocking scenarios and notifications
- Display of last login and last access timestamps to authenticated users upon successful login
- Notification of remaining login attempts to users before account blocking
- Option to disable core login error messages to prevent information disclosure to attackers
- Event tracking database that stores all login attempts with automatic cleanup via cron
- Clear event tracking button to manually reset all tracked login attempts
- Email notifications with customizable subject and body for both user blocking events and ongoing attack detection
- Migration support from Drupal 7 including settings and tracking data
Use Cases
Protecting against brute-force attacks
Configure the module with: Track time = 60 minutes, User blocking = 5 attempts, Soft host blocking = 10 attempts, Hard host blocking = 15 attempts, Attack detection = 50 attempts. This configuration will block individual user accounts after 5 failed attempts from any IP, temporarily block IPs after 10 failed attempts, permanently ban IPs after 15 failed attempts, and alert administrators when 50+ failed attempts are detected within an hour.
High-security environment with email alerts
For sensitive sites, configure low thresholds: User blocking = 3 attempts, Soft host blocking = 5 attempts, Hard host blocking = 8 attempts, Attack detection = 20 attempts. Configure notification emails for both user blocking and attack detection. Enable 'Disable core login error message' to prevent username enumeration attacks. This setup provides aggressive protection and immediate awareness of any suspicious activity.
Public community site with lenient settings
For sites where blocking legitimate users is a concern: Set User blocking = 0 (disabled) to prevent attackers from locking out real users. Use Soft host blocking = 20 attempts and Hard host blocking = 50 attempts. Enable 'Notify user about remaining attempts' so legitimate users know they're approaching limits. This balances security with usability on high-traffic public sites.
Migrating from Drupal 7
When upgrading from Drupal 7, the module provides migration paths for both settings and tracking data. Use drush migrate:import d7_login_security_settings to import your D7 configuration and drush migrate:import d7_login_security_track to import existing tracking data. The migration automatically converts username-based email notifications to email address-based settings.
Compliance with security audits
Enable 'Display last login timestamp' and 'Display last access timestamp' to help users identify unauthorized access to their accounts. Configure attack detection with email notifications to maintain audit trails. The watchdog logs created by the module (under 'login_security' type) provide detailed records for security audits.
Tips
- Set track_time appropriately for your security needs - shorter times (60 minutes) are more lenient, longer times (1440 minutes / 24 hours) are more strict
- Always configure notification emails for attack detection to be immediately aware of security threats
- Use the watchdog logs (Reports > Recent log messages, filter by 'login_security') to monitor blocking events and attack patterns
- Consider enabling 'Disable core login error message' to prevent username enumeration attacks, especially on high-security sites
- User uid 1 is never blocked by the user blocking feature - use host blocking protections for additional security
- Test your configuration by intentionally triggering blocks to verify email notifications work correctly
- The 'Clear event tracking information' button is useful after changing settings or resolving a blocked situation
- Message tokens like @username, @ip, @site allow personalized messages - review available tokens in the settings form
Technical Details
Admin Pages 1
/admin/config/people/login_security
Configure login security settings including blocking thresholds, notification options, and customizable messages for various blocking scenarios. This page allows administrators to set up multi-layered protection against brute-force login attacks.
Hooks 1
hook_login_security_display_block_attempts_alter
Allows modules to alter the display of remaining login attempts message and whether to show it at all.
Troubleshooting 6
Increase the user_wrong_count threshold or set it to 0 to disable user blocking. Consider using only soft and hard host blocking which target IP addresses rather than user accounts.
Soft blocks expire based on the track_time setting. Verify the track_time value (in minutes) is set appropriately. Run cron to ensure expired events are cleaned up. You can also manually clear all tracking data using the 'Clear event tracking information' button on the settings page.
Hard blocks are permanent and stored in the ban_ip table. Unblock IPs at Administration > Configuration > People > IP address bans (/admin/config/people/ban).
Verify the email addresses in the notification settings are correct. Check that your site's email system is working (test with other emails). Ensure the threshold values are set (non-zero) and the configured threshold has been reached.
This is by design. The super admin account (uid 1) is intentionally excluded from user blocking protection because it's commonly targeted and easily discovered. Use a combination of other protections (soft/hard host blocking) to protect against attacks targeting uid 1.
The module maintains state to prevent repeated notifications. An attack alert resets when tracked events drop below 1/3 of the threshold. If you want to reset this manually, clear the state variable or use the 'Clear event tracking information' button.
Security Notes 8
- User uid 1 (super admin) is intentionally never blocked by the user blocking feature. This is because uid 1 is easily discovered (often named 'admin') and could be trivially locked out. Rely on host blocking for additional protection.
- Soft blocks only prevent login form submission - users can still browse the site anonymously. Use hard blocking for complete denial of access.
- Hard blocks use the Ban module and are permanent until manually removed by an administrator.
- Disabling core login error messages improves security by preventing username enumeration but may confuse legitimate users.
- The notification message about remaining attempts may inadvertently disclose your security policy to attackers - configure this message carefully.
- Email notifications only work if email addresses are configured and your site's mail system is functional.
- Event tracking data is stored in the database - consider privacy implications and retention policies for GDPR compliance.
- Session IDs are not considered in security operations because automated brute-force tools typically request new sessions on each attempt.