Laraguard Laravel Package

Technical Evaluation

Architecture fit

• Laravel-idiomatic package: service provider, publishable config and migration, middleware, events, validation rules, and JSON/Blade responses. It slots into a standard Laravel app with no architectural change to the surrounding code.
• Fully on-premises: TOTP secrets stored per user, verification computed locally. No SaaS dependency, no per-authentication cost, no data egress — a genuine advantage for data-residency, air-gapped, or procurement-averse environments.
• Contract-driven (a TwoFactorAuthentication contract with a default implementation), so the call sites are swappable — but the implementation you would actually depend on is the archived one.
• Opinionated scope: TOTP plus recovery codes plus "safe device" trust. No WebAuthn/passkeys, no SMS, no push. If the product roadmap includes phishing-resistant factors, this package is a dead end regardless of maintenance status.

Integration feasibility

• The gating issue is time. Last release February 2022, repository archived. That predates Laravel 10, 11, and 12. Expect Composer constraint conflicts on laravel/framework/illuminate/* and potentially on Carbon and the QR-code dependency.
• On a Laravel 8/9, PHP 8.0/8.1 estate it will likely install cleanly and work as documented. Above that, "integration" means forking and widening constraints — at which point you own the authentication code.
• Documentation is frozen at the 2022 state; there is no upstream to ask, no issue triage, and no patch channel.

Technical risk, ranked

1. Unmaintained code on the authentication path. 2FA sits in front of every login. No CVE response, no patches. Any flaw in TOTP validation, replay protection, recovery-code handling, or rate limiting becomes your incident, and you find out from a researcher rather than a maintainer.
2. Dependency anchor. Transitive pins age out and start blocking unrelated upgrades. This package can quietly become the reason the platform cannot move off an EOL framework — which is a larger security exposure than the package itself.
3. Verification burden falls on you. Independent review is required for: TOTP window/drift tolerance, replay of a used code, recovery-code one-time use and storage (hashed vs plaintext), rate-limiter behavior when the cache is unavailable, and secret encryption at rest plus behavior under APP_KEY rotation.
4. Hidden state. Safe-device trust cookies and attempt counters live in cache/session. Behavior varies by cache driver and by whether web and worker nodes share a store — a silent degradation risk.
5. No upstream, ever. Archived means every fix, compatibility bump, and security patch is internal work with a permanent owner requirement.

Key questions

• What Laravel and PHP versions are in the target estate, and is there a dated framework upgrade on the roadmap? If yes, option A is off the table immediately.
• Is Fortify or any other 2FA already present or planned? If so, this package is redundant capability.
• Who owns a fork — named team, on-call rotation, security review cadence, CI?
• Will security and audit accept an archived third-party package on the authentication path? Get this in writing before designing around it.
• Do we need factors beyond TOTP within the planning horizon?
• If we adopt now and replace later, are the enrolled secrets portable, and what is the re-enrollment cost across the user base?

Integration Approach

Stack fit

• Good fit: Laravel 8/9, PHP 8.0/8.1, conventional Eloquent user model, shared Redis cache, stable release cadence.
• Poor fit: Laravel 10+, or any estate with a supported-dependencies-only policy.
• Neutral: no vendor onboarding, no DPA, no network dependency — simplifies security review and removes an external availability risk from the login path.

Migration path — three viable options

• A. Adopt as-is. Only defensible if the estate is pinned to Laravel 9 and a migration decision is already funded and scheduled. Treat it as a bridge, not a destination.
• B. Fork and vendor. Copy into packages/ or a private VCS, widen constraints, add test coverage and CI, assign an owner, and register it as internal code. This is the honest cost of adopting an archived package.
• C. Replace. Laravel Fortify's built-in 2FA, pragmarx/google2fa-laravel , or a passkey-capable option. Default recommendation unless A's constraints dominate and the timeline is short.

Compatibility checks before committing

• Published migration does not collide with existing schema; secret column encryption matches the app's key-rotation policy.
• Middleware aliases and ordering: the 2FA challenge must run after auth and before protected routes, and must not interfere with API token auth.
• Rate-limiter cache store exists and is shared across all web and worker nodes in every environment.
• Composer resolution verified against the actual lockfile, not just the manifest.

Sequencing

1. Spike, 1–2 days. Scratch app on the target framework version: install, migrate, enroll via QR, verify, use a recovery code, trust a device, disable 2FA. Confirms feasibility cheaply.
2. Security review. Read the TOTP, recovery-code, and rate-limiter code directly. Write adversarial tests: replayed code, clock skew, brute-force cadence, cache-down behavior, key rotation.
3. Decide fork vs replace, with the security review as input. Record the decision.
4. Pilot behind a feature flag on an internal cohort. Instrument enrollment completion, verification failure rate, recovery-code usage, and lockouts.
5. Roll out with a documented break-glass path, then add the entry to the dependency register with an explicit re-review date.

Operational Impact

Maintenance

• Highest ongoing cost of any option considered. An unmaintained package on the auth path must be budgeted as internal code: periodic dependency bumps, re-validation on every framework upgrade, and a standing security review. There is no upstream to absorb any of this.

Support

• No vendor, no maintainer. Support is your on-call rotation. Minimum runbook set: user lost device, recovery codes exhausted, admin-forced reset, secret decryption failure, mass lockout after a key event.

Scaling

• Strong on runtime cost. Verification is local compute plus one row read; no per-login network hop, no third-party rate limits, no per-MAU pricing. This is the package's best argument.
• Watch items: writes on secret rotation and recovery-code regeneration, and the requirement that rate-limit counters live in a shared store rather than per-node arrays.

Failure modes to design for

• Clock drift / NTP skew on app nodes → valid codes rejected at scale. Enforce NTP; confirm and document the accepted window.
• Cache outage → rate limiting silently bypassed (brute-force exposure) or challenge errors. Fail closed and alarm.
• APP_KEY rotation → encrypted TOTP secrets unreadable, mass lockout. Add to the key-rotation runbook and test it.
• Recovery-code exhaustion → support burden and social-engineering risk during manual recovery.
• Framework upgrade block → the package pins the platform to an EOL Laravel, becoming a larger exposure than the package's own code.
• Fork drift → your fork diverges from any community successor, complicating a later exit.

Ramp-up

• Low to integrate: a Laravel developer can have a working enrollment flow in days.
• Moderate to high to own safely: sign-off requires fluency in TOTP/RFC 6238 semantics, Laravel encryption and key handling, and auth middleware ordering.
• Process overhead is the real onboarding cost: dependency register entry, security review, runbooks, and a written decision record explaining why an archived package was placed on the authentication path.

Bottom line. Technically a clean fit for the Laravel idiom and cheap to run, but the archived status makes it a poor default for a security-critical surface. Prefer a maintained alternative or Fortify's built-in 2FA. Adopt laraguard only with an owned fork, a completed security review, a named maintainer, and a documented exit plan.