Nova Google2Fa Laravel Package

Technical Evaluation

Architecture fit. The package is a standard Laravel Nova tool: a Composer package with a Nova tool class, service provider, and auto-discovery that registers via Nova::tools() in NovaServiceProvider. It rides Nova's public extension surface rather than patching core, which is the right shape for this kind of capability — nothing to maintain in our application code beyond config and migrations. Note the scope distinction up front: this secures the Nova admin panel login, not end-user accounts (that's Fortify/Jetstream territory). It fills a real gap, since Nova ships no native TOTP second factor.

Integration feasibility. Mechanically simple. Expect composer require, publish config and migrations (either additive columns on users or a dedicated table), register the tool, optionally add a middleware for challenge enforcement. Realistic spike effort is 1–2 engineer-days, and most of that is validation and manual security testing, not code. The only thing the fork claims to change is Nova 4 compatibility — which sets the evaluation bar: we are adopting an unvalidated patch of a known-good idea, so the diff is the product.

Technical risk. High, and concentrated in provenance rather than code.

• Zero social proof. 0 stars, 0 dependents, no score, no issue history. There is no evidence of production use anywhere, which means no one else has absorbed the edge cases for us.
• Fork, not upstream. Forking is a maintenance commitment transfer. We inherit CVE triage on the transitive pragmarx/google2fa and QR-code dependencies with no upstream security process behind us.
• Security-critical surface. TOTP enrollment, secret storage, recovery codes, and login-challenge middleware. A misconfigured middleware is an auth bypass; a weak recovery flow is a permanent lockout vector. This is the worst category of package to take on faith.
• Fragility curve. Nova 5 will likely break it. google2fa 8.x/9.x moved to PHP 8.1+ and dropped older encrypter paths — version resolution may conflict with our Laravel/PHP pin.

Key questions for the maintainer (or for our own source review).

1. What is the exact diff from carloscgo/nova-google2fa? One constraint bump, or a reimplementation?
2. Are TOTP secrets encrypted at rest via Laravel's encrypter, or stored plaintext?
3. Are recovery codes hashed and single-use? How many, and how are they regenerated?
4. Is 2FA opt-in or enforceable per user/role? Is there a "remember this device" cookie, and what is its lifetime?
5. Does a break-glass path exist — an artisan command or Nova action to reset 2FA for a locked-out admin?
6. Which google2fa and PHP versions are constrained, and does it tolerate replay/clock drift?
7. What is the license, and is there any CLA or provenance concern with re-publishing under a new namespace?

Integration Approach

Stack fit. Target is Laravel 9/10 + Nova 4 + PHP 8.1/8.2, which matches most current estates. Confirm the composer.json constraints against our actual pins before anything else — Composer will surface conflicts in minutes, and a nova constraint of ^4.0 with a hard google2fa pin is the likely friction point. If we are on Nova 3, this package is irrelevant; if we are planning Nova 5 within the year, that is a reason to prefer a self-owned implementation.

Migration path. Treat this as code we are adopting, not a dependency we are consuming:

1. Vendor it. Fork into our own org or, at minimum, pin a commit SHA (never a branch) in a private VCS repository or Satis/Satis-like private registry.
2. Add it to CI with composer audit and Dependabot/Renovate so transitive advisories reach us.
3. If the source review turns up gaps (likely on recovery codes and break-glass), patch internally and own the patch. At that point, the honest comparison is "a week of in-house work against pragmarx/google2fa directly" — that path removes fork risk entirely and is worth pricing before committing.

Compatibility. Migrations must be additive and reversible; verify they do not collide with existing columns if any prior 2FA attempt exists in the schema. Check that the tool registers cleanly alongside our existing Nova tools and that no global middleware is injected (some 2FA packages add a global middleware that can interfere with API routes). Confirm Nova 4's authentication flow — the challenge redirect has to hook the Nova login guard, not the default web guard, or it silently does nothing.

Sequencing.

1. Source review of the diff vs upstream (half a day, security-literate engineer).
2. Throwaway-environment spike: install, enroll, verify, disable.
3. Manual security test matrix: enroll / verify / wrong code / recovery code / lost device / admin reset / re-enroll / APP_KEY rotation.
4. Internal fork + CI + dependency scanning.
5. Pilot with a small admin group behind a config flag.
6. Org-wide enforcement with a published break-glass runbook.

Do not enforce org-wide until step 3 is signed off by whoever owns security.

Operational Impact

Maintenance. No upstream velocity to lean on — assume near-zero. Budget 2–4 engineer-days per year for dependency bumps and Nova upgrade remediation, plus reactive time when google2fa publishes an advisory. The package is small enough that a single engineer can hold the whole thing in their head, which is the main mitigating factor.

Support. No vendor, no SLA, no documentation beyond a README. Effective support model is internal: one named owner, a runbook, and a documented decision record explaining why we forked rather than built. If we cannot staff that owner, we should not deploy this.

Scaling. A non-issue. Verification is one indexed read per login plus an HMAC computation; QR provisioning is a one-time render. Even at thousands of admin logins per day this does not register against any capacity plan. The binding constraint is human, not compute.

Failure modes. Ranked by likelihood-times-damage:

• Admin lockout — lost device with no working recovery path. Highest-probability, highest-damage. Requires a tested break-glass command and an on-call path to it.
• APP_KEY rotation — if secrets are encrypted with the app key, rotation invalidates every enrolled device simultaneously. Must be documented as a coupled change, with re-enrollment planned alongside.
• Silent middleware bypass — a Nova or Laravel upgrade changes the login flow and the challenge stops firing. 2FA appears enabled and enforces nothing. Mitigate with an automated login test asserting the challenge is presented.
• Dependency conflict blocking a Nova upgrade — the fork becomes the reason we cannot patch Nova, which is a bad trade for an admin convenience feature.
• Clock drift — window-of-acceptance misconfiguration produces intermittent "invalid code" reports that read as user error.

Ramp-up. Engineering ramp is trivial — a Laravel developer is productive in half a day. Organizational ramp is the real cost: this needs a security owner, a comms plan for enforced enrollment, user-facing instructions for authenticator apps, and a documented recovery procedure before the first enforced login. Plan the policy work in parallel with the technical spike, not after it.

Recommendation. Approve for a time-boxed spike only. Do not adopt as-is on the strength of the repository signal — there is none. The decision points that matter are (a) whether the source review shows sane secret storage and recovery handling, and (b) whether we would rather spend roughly a week owning a 200-line implementation than own someone else's abandoned fork. Both are cheap to answer and should be answered before this reaches any admin who cannot afford to be locked out.