Why is my WP site receiving failed login attempt notifications after disabling passwords with Clef?

First, attackers can send spoofed HTTP POST requests to your WP site's login script whether or not you hide the login form via Clef 2FA's settings.

Second, in addition to running the Clef 2FA plugin, your site is running one or more firewall plugins, which produce such notifications (e.g., iThemesSecurityLimit Login AttemptsNinjaFirewallWordfenceSucuri, et al.).

Clef 2FA respects the proper order of handling WordPress HTTP requests on the application layer: firewall plugins process all requests first, then Clef processes all  authentication requests. Since firewall plugins are first in line, you will continue to receive notifications as long as you keep the notification setting of the firewall turned on.

Do these notifications mean that Clef 2FA is failing to protect my site?

No. Whether or not you run a firewall plugin in addition to Clef 2FA, Clef 2FA will protect both of WP’s authentication doorways (i.e., wp-login.php and xmlrpc.php) against the full gamut of password-based attacks.

Is it safe to turn off these notification emails in my firewall plugin?

It's up to you: whether they are on or off does not affect Clef 2FA's operation.

If I use Clef 2FA, does it make sense to keep using other security/firewall plugins?

Clef 2FA is more than capable of ensuring authentication security for your WP site all by itself. All Clef-enabled users on your WP site are fully protected from the full array of password-based attacks including brute-force bots.

Nevertheless, other WP security plugins and good networking practices can protect additional vectors beyond authentication on the application layer. For this reason Clef 2FA is designed to integrate well with other top-tier WP security plugins.

Whether you choose to activate other security plugins along with Clef 2FA involves a judgment call based on several considerations:

    <li>an understanding of the interrelated networking-, server-, and application-layer considerations involved in securing a WP site (see “<a href="http://codex.wordpress.org/Hardening_WordPress">Hardening WordPress</a>”; “<a href="https://www.owasp.org/index.php/OWASP_Wordpress_Security_Implementation_Guideline">OWASP Wordpress Security Implementation Guideline</a>”)</li> <li>an understanding of what security vector the Clef 2FA plugin protects (i.e., it provides authentication security for wp-login.php and xmlrpc.php) and where it operates in the networking stack (i.e., on the application layer; specifically on WP’s <a href="https://codex.wordpress.org/Plugin_API/Action_Reference/init">init hook</a>)</li> <li>an understanding of what security vectors the other security/firewall plugins protect and which layers they utilize in the networking stack</li> <li>the specifics of the WP site in question (i.e., number of users, size of audience, web hosting and networking configuration)</li> <li>and your security goals.</li>

I'm not a security or networking expert, but I know my WP site is receiving unwanted login attempts, and I care about my site's security. What should I do?

First, relax. For most WP sites installing the  Clef 2FA plugin is sufficient for defeating the full array of authentication-related attacks.

Second, if you wish to step up your WP site's security game, consider one or more of the following well-attested strategies:

  1. Activate one of the following firewall/security plugins:
    1. the Jetpack plugin, and turn on the Protect module (easy setup: one-click module activation).
    2. the Wordfence plugin (moderate setup: configuration is required). More features and configuration options than Jetpack Protect means more control but also a higher learning curve up front. The settings are well documented. WF recently added a WAF that operates similar to NinjaFirewall (see below).
    3. the NinjaFirewall plugin (moderate setup: configuration is required; settings are well documented). NinjaFirewall is a PHP-based WAF that filters HTTP requests at the web server layer (i.e., before WP is loaded) for highly efficient operation; see benchmarks.
  2. Filter requests at the network layer before they reach your web server by using a reverse proxy such as:
    1. AWS WAF
    2. Cloudflare (reputation-based IP filtering and basic DDoS protection on free tier; WP-specific WAF rule set available on paid tiers)
    3. Incapsula (WAF)
    4. Max CDN (WAF-like features)
    5. Naxsi (local WAF for NGINX; WP rule set available)
    6. Sucuri (WP-specific WAF service)
  3. Employ TLS/SSL (strongly recommended by WP.com) to avoid sending user credentials in plain text to /wp-login.php and /xmlrpc.php. To do so either purchase a SSL certificate from your hosting provider, or consider a free alternative such as:
    1. Cloudflare's SSL (available on free tier). If using the Flexible SSL option, note (a) the CF Flexible SSL plugin and (b) the link protocol re-writing option in the official CF plugin)
    2. LetsEncrypt (free certificates)
    3. Startcom (free certificates)
    4. Sucuri SSL (reverse-proxy-based SSL similar to CloudFlare’s SSL)