Contrib.social

[PP-1][2.x] Do not execute other form validations if CAPTCHA is wrong

Open on Drupal.org →
Created on 10 March 2021, almost 4 years ago
Updated 27 December 2023, 12 months ago

Problem/Motivation

If captcha is wrong, there is stilll a request on database for login forms, which may make password guessing easier: ( #2967588: Captcha allow to guess passwords → ).
For other forms, other form-specific validations are also executed, which should not be run if CAPTCHA fails.

So this is a very special case for CAPTCHA. providing additional security, see #8.

Steps to reproduce

I have implemented this is on my site login

Enter username and password wrong and also enter the wrong captcha it still will validate the user details even if the captcha is wrong which in turn increases the load on the database and server. Either if captcha is then only requested must proceed to server side

For example, if a bot is making submissions will down the site for sure

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Postponed

Version

2.0

Component

Code

Created by

🇮🇳India akshay.singh Noida

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 12 months ago →
    🇳🇿New Zealand quietone

    I don't think that this should be a child of core issue. Typically, core issues with children are closed when either all the children are closed or there is one remaining child. With this as a child that makes a core issue dependent on the completion of a contrib issue which it should not be. I have confirmed this with another core committer. Therefore, I am removing the parent.

  • Comment 12 months ago →
    🇩🇪Germany Anybody Porta Westfalica

    Thanks @quietone - using related issues instead is fine. The parent issue thing was meant to show the core issue is a hard blocker for this important and widely used module.

    Thanks for the correction!

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024