Complexify Bundle Laravel Package

Technical Evaluation

Architecture fit. There is a categorical mismatch here that dominates the evaluation: this is a Symfony2 bundle, not a Laravel package. Laravel consumes individual Symfony components (HttpFoundation, Console, Process), but it has no mechanism to load a Symfony bundle — the bundle's actual payload is DI extension classes, a Configuration tree, and service definitions in YAML/XML, none of which the Laravel container can read. The genuinely reusable asset is one PHP class that takes a password string and returns a 0–100 complexity score. That is a ~200-line algorithm, not an integration surface.

Second architectural point: Complexify is a client-side feedback heuristic (jquery.complexify.js) with a PHP port bolted on. Its design intent is live keystroke feedback in the browser. If we adopt the PHP side, we now own two implementations of the same scoring model that can disagree — user sees "strong" in the UI, server logs "weak," or vice versa. Any adoption decision must pick one authoritative side, not both.

Integration feasibility. composer require lightmaker/complexify-bundle into a Laravel application is not a supported path. Feasible options are (a) vendor the underlying standalone PHP port (mcrumley/php-complexify) as a plain library dependency, or (b) fork/extract the scoring class into our own namespace. The MIT license makes extraction legally clean and low-friction. Engineering effort is small — low single-digit days for a spike — but we take ownership of unowned code.

Technical risk: High.

• Abandonment. Last release 2016-04-29 — roughly nine years. Symfony2 reached end of life in January 2017. There is no maintainer, no issue triage, and no security advisory channel.
• Runtime compatibility is unverified. Code of this vintage typically assumes PHP 5.6/7.0 semantics. Expect friction on 8.x: dynamic properties, each(), curly-brace string offsets, implicit nullable parameters, missing return types. This must be proven with a test matrix, not assumed.
• Zero social proof. 0 stars, 0 dependents, 0 forks of note. The 0.23 composite score against a 13.81 opportunity score reads as "a real capability category, wrapped in a package nobody has validated." No dependents means no ecosystem has stress-tested this code in production.
• Domain staleness. Password-strength scoring is security-adjacent. This model predates NIST SP 800-63B guidance (length + breached-password blocklist over composition rules). Shipping it risks encoding an outdated password policy into the product, and the dictionary of common passwords will be years behind current breach corpora.
• Silent incorrectness. A strength score that is subtly wrong produces no error, no alert, no log line — it just quietly approves weak passwords. This is the worst failure class for a security-adjacent component.

Key questions for the team.

1. Is the requirement server-side enforcement or client-side UX feedback? Most of this package's value disappears if the answer is "feedback only."
2. Has anyone compared this against bjeavons/zxcvbn-php? zxcvbn is actively maintained, has a real dictionary/matcher model, and is the de facto standard.
3. What is NIST 800-63B / internal policy alignment — do we actually want composition-rule scoring at all?
4. Does Complexify need to run per keystroke, per submit, or both? This determines whether we incur request amplification.
5. Who owns the fork when the original author is unreachable and a CVE-relevant bug lands?
6. Do we need UTF-8 / non-English password support, and does the dictionary matcher degrade acceptably there?

Assessment: do not adopt the package. If the capability is required, adopt a maintained library or write ~150 lines in-house.

Integration Approach

Stack fit. Treat this as algorithm sourcing, not package integration. Two viable shapes:

• Preferred: add bjeavons/zxcvbn-php via Composer, bind it behind a first-party PasswordStrength contract, and expose it through a thin Laravel service provider plus config file. Actively maintained, no Symfony legacy, native Laravel compatibility.
• Fallback (only if Complexify's specific score curve is a hard requirement): extract the scoring class into our own namespace (App\Support\Security\ComplexifyScorer or an internal acme/password-complexify package), add a PSR-4 autoload entry, and own it permanently. Do not pull in the bundle's DI/config layer at all.

Migration path. Depressingly simple, in a good way: with 0 dependents and 0 stars there is no ecosystem lock-in and nothing else to migrate. MIT license removes legal friction for a fork. The migration that actually matters is the future one — off Complexify and onto zxcvbn, or off entropy scoring entirely and onto a length + breached-password-blocklist policy. Design the interface so that swap is a one-class change.

Compatibility. Validate explicitly before committing:

• Declared PHP constraint vs. our runtime (assume 8.2/8.3 — expect breakage).
• PSR-4 autoload correctness and absence of global function/constant pollution.
• Behavior on empty string, null, password > 1,000 chars, and multibyte input (no strlen/byte-offset assumptions).
• Determinism: same input must yield the same score across processes; no locale or setlocale sensitivity.
• Whether the bundle brings transitive Symfony2 constraints that would conflict with Laravel's Symfony component versions in composer.lock. This alone is likely a hard blocker for direct installation.

Sequencing.

1. Spike (1–2 days): stand up Complexify and zxcvbn side by side against a corpus of ~200 real passwords (weak, strong, passphrase, non-English, correcthorsebatterystaple-style). Compare scores and false-positive/false-negative behavior.
2. Decide policy: confirm against NIST 800-63B and internal security guidance whether we need score-based strength at all.
3. Define contract: PasswordStrength::score(string $plain): StrengthResult with a StrengthResult value object (score, verdict, reason codes). Ship the interface with no implementation dependency leaking out.
4. Implement + test: adapter over the chosen library; unit tests including Unicode and boundary-length cases.
5. Feature-flag and shadow-mode: run server-side scoring in log-only mode for 2–4 weeks to measure disagreement with whatever is currently shipping, before it gates anything.
6. Enforce, then delete the flag.

Operational Impact

Maintenance. Under any Complexify path, we are the maintainer. Budget for a fork under an internal namespace, a PHP-version CI matrix, and a documented owner. That is a permanent, if small, tax. Under the zxcvbn path, maintenance is an upstream-upgrade task — materially cheaper over a 3-year horizon.

Support. No upstream support, no issue triage, no CVE feed for the package itself. The MIT license is explicit about no warranty. Any defect is ours to diagnose with zero external help, and the original authors are effectively unreachable a decade on. For a component adjacent to authentication, this is a governance gap, not just an inconvenience.

Scaling. The algorithm itself is trivial: pure in-process CPU, no I/O, no network, no shared state — it will never be the bottleneck on a request path. The real scaling concern is request amplification: Complexify's model assumes a score per keystroke. Calling it server-side per keystroke turns every password field into dozens of extra requests per user session. Score on submit only; if live feedback is required, keep it client-side and treat the server score as authoritative. Also cap input length (e.g., 1,024 chars) to bound dictionary-matching cost — unbounded password inputs are a cheap CPU-exhaustion vector.

Failure modes.

• Silent mis-scoring — no exception, just a wrong verdict. Highest-severity, lowest-visibility risk. Mitigate with shadow-mode validation and a regression corpus.
• Runtime breakage on PHP upgrade — legacy syntax fails fatally at autoload or first call; caught by CI, not by users, if the matrix exists.
• Client/server disagreement — two implementations of the same model drift; users get contradictory guidance; support tickets.
• Multibyte/Unicode degradation — byte-oriented logic under-scores or throws on non-ASCII passwords, systematically disadvantaging non-English users.
• Dictionary staleness — weak passwords score as acceptable because the blocklist is years old.
• Dependency conflict — Symfony2 constraints in the bundle collide with Laravel's Symfony components in Composer resolution; discovered at install, not at design.
• Abandonment mid-audit — a security review flags the dependency and there is no upstream to remediate with; forces an emergency fork or rip-out.

Ramp-up. Low in absolute terms — a mid-level Laravel engineer can absorb the interface and adapter in under a day, and a security engineer can review the scoring model in an afternoon. The hidden cost is legacy fluency: anyone asked to actually debug inside Symfony2 bundle conventions (DI extensions, Configuration trees, XML service definitions) is working with skills that have been dead for close to a decade. We should not plan on having that expertise available on demand.

Bottom line for the roadmap. The 13.81 opportunity score correctly identifies password-strength estimation as a live capability area; the 0.23 package score correctly identifies this specific artifact as unusable as a dependency. Fund the capability, not the package — and fund it behind a first-party interface so the choice of scoring engine stays an implementation detail rather than an architectural commitment.