User login via route user.login.http bypasses TFA

Created on 24 November 2022, almost 2 years ago
Updated 12 July 2023, about 1 year ago

Problem/Motivation

Any existing user can by-pass the tfa by logging in via the login API defined by the route 'user.login.http'.

Steps to reproduce

POST the request via ./user/login?_format=json (with the correct json object in the body of the request, containing the values for "name" and "pass").

Proposed resolution

Since, some programmers (using tfa in a decoupled setting) might want to write their own API that takes care of this user login, I suggest a configurable way to prevent this login via the API.

This will allow Drupal installations where user login takes place via the back-end to close this route.

Ideally, the module would make an API that overrides the routing for 'user.login.http' that takes 3 parameters (name, pass and code) and takes care of the two-factor authentication and user login, and ideally this override can be switched on (and off) in the TFA configuration.

According to me, that is. Maybe a better solution can be envisioned.

🐛 Bug report
Status

Closed: outdated

Version

2.0

Component

Code

Created by

🇳🇱Netherlands Ronald van Belzen

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

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

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.

  • 🇺🇸United States cmlara

    Categorizing release blockers.

  • 🇺🇸United States cmlara

    Failed to set severity.

  • Status changed to Closed: outdated about 1 year ago
  • 🇺🇸United States cmlara

    I'm going to close this as outdated, were going to handle this in [#374221].

    This was fixed in 8.x-1.x as part of SA-CONTRIB-2023-030.

    At the time this issue was opened neither 8.x-1.x nor 2.x was stable, as such this issue complied with the Drupal Security Team(DST) policy regarding when to open an issue in public or private.

    Now that I have been added to the modules development team I would request that in the future (even if the DST says an issue may be public) that issues be brought to me privately so that we may evaluate the impact and fix the issues before the public have a chance to exploit them.

    Note:
    I requested on December 30th 2022 that the DST mark this issue private to allow it to be handled with an official SA since it impacted a known stable version, that action was never taken by the DST.

Production build 0.71.5 2024