Adopt a 'security first' focus

Created on 28 June 2023, over 1 year ago
Updated 19 November 2023, about 1 year ago

Problem/Motivation

In at least a couple of issues a maintainer has expressed a preference that reducing the number of support requests has a higher priority than secure defaults.

See:
#3319617-6: Disallow viewing recovery codes after first display β†’
#3353326-2: Remove TOTP/HOTP plugins from TFA module (adding was a regression) β†’

While the existing samples are relativity minor, to me this raises a concern about how every decision may be looked at and are we not catching areas that should be set in a secure manner rather than an insecure manner.

Such an ecosystem also discourages the reporting of security hardening that may increase developer effort which could lead to future publicly exploitable security vulnerabilities.

Steps to reproduce

N/A

Proposed resolution

Adopt policy that:
Configuration should wherever possible be shipped with secure defaults.
Code should be designed to to 'fail secure' with a preference for refusing logins and only when everything works successfully granting them.

Remaining tasks

Discuss
Adopt

User interface changes

None

API changes

None

Data model changes

None

✨ Feature request
Status

Fixed

Version

2.0

Component

Miscellaneous

Created by

πŸ‡ΊπŸ‡ΈUnited States cmlara

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @cmlara
  • Status changed to Postponed: needs info over 1 year ago
  • πŸ‡΅πŸ‡ΉPortugal jcnventura

    I don't see anything actionable here. Even with as many flaws as the module may have, since it is hacking into Drupal's user login workflow which was not designed to be extendable, the current code already tries to ship with secure defaults, and to forbid login.

    I know what you are really talking about, but I think that without a major drive from to have 2FA or at a least a more extendable login process in Drupal core, the policy that you are requesting is the same as: "Please re-implement all the user login functionality in the module, and while at it remember to re-implement every other core service that deals with user authentication". It is honestly not too far away from "please maintain a fork of Drupal core".

    So my question to you is... Do you want to be a co-maintainer and do this yourself?

    a maintainer has expressed a preference that reducing the number of support requests

    It is not about reducing the number of support requests.. It's about reducing the effort necessary to maintain the module, of which there is sincerely very little capability at the moment.

  • Status changed to Active over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    To be honest, with this particular issue I really am intending on focusing on the secure defaults, that when were adding new features, and were evaluating the road-map for the future that we choose the methods that make TFA as secure as it can be (for example ✨ Disallow viewing recovery codes after first display Active the change would be that we would instead of preferring to allow recovery codes to be visible by default, we would prefer that they not be viable by default).

    I know what you are really talking about.... So my question to you is... Do you want to be a co-maintainer and do this yourself?

    We do have that other side discussion that I would like to see move forward though that honestly wasn't the primary driver for this issue, more I wanted to see if I should start submitting other restructurings as part of 2.x that will increase developer effort where we restructure from 'assume everything is working" to "assume nothing is working" in efforts to harden parts of the code that maybe never actually pose an issue but we can reduce the risk so that should those incidents ever happen its already mitigated.

    That said yes I am willing to co-maintain and push through these additional tasks, and the other side tasks we have discussed, along with helping clear out the current queue in order to bring TFA to a more solid footing.

  • Status changed to Fixed about 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    I believe we can consider this issue 'fixed'.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024