Hashing Laravel Package

Technical Evaluation

Architecture fit. marko/hashing is a single-responsibility leaf package: password hashing and verification for applications built on the Marko Framework. It has no downstream dependencies of its own beyond the Marko container and its contracts, which makes it architecturally cheap to adopt and cheap to remove. The fit question is therefore binary — it is a strong fit inside a Marko codebase and a non-fit anywhere else. It is a read-only split of the marko-php/marko monorepo, so in practice it should be treated as a component of the core framework's release train rather than as an independent library.

Integration feasibility. Expected effort is low: a Composer require, a service-provider/container binding, and a small configuration surface (driver selection plus cost/parameter tuning). The real diligence is not integration effort but confirming the package's declared constraints against the core marko/marko version in use, and confirming the API shape (a hasher contract with make/check/needsRehash-style methods, or equivalent) before designing auth flows around it. Because it is the framework's sanctioned primitive, the alternative — hand-rolling password_hash/password_verify in application code — is strictly worse from a standards and auditability standpoint.

Technical risk. The blast radius is small but the severity ceiling is high: this package sits directly on credential storage. Three risks dominate. First, split-repository governance — the repo is read-only, so patches, issue triage, and security advisories route through the monorepo, which adds coordination latency and makes vulnerability visibility dependent on monitoring the parent project rather than this package. Second, weak external validation — 0 stars and 0 dependents are largely artifacts of the split (subpackage repos structurally accumulate no stars), so they should be discounted, but they do mean there is no third-party ecosystem pressure or independent usage evidence to lean on; weigh parent-repo health and test coverage instead. Third, cryptographic surface — algorithm support, parameter defaults, timing-safe comparison, and rehash-on-login behavior all need explicit verification rather than assumption.

Key questions.

• Which algorithms are supported (bcrypt, argon2id, scrypt), and which is the default?
• Does it wrap PHP's native password_hash/password_verify, or implement its own comparison? This determines whether existing bcrypt hashes verify transparently.
• Is there a needsRehash capability, and is it wired into the authentication path or left to the application?
• How are cost/parameter values configured and validated, and are they environment-specific?
• What PHP version and extensions are required (sodium, openssl) — and does the production image satisfy them?
• Is the API stable (1.0+) or still moving with the core framework?
• Where do security advisories for this package get published?

Integration Approach

Stack fit. Adopt only if Marko is already the standard application framework. Within that constraint this is the correct default and should be mandated in the internal engineering standard, replacing ad-hoc password_hash calls. For Laravel, Symfony, or plain-PHP services, this package offers nothing that the framework-native hasher or the language's native functions do not.

Migration path. The critical unknown is hash compatibility. If the package delegates to PHP's native password API, existing bcrypt/argon2 hashes produced elsewhere verify unchanged and migration is a no-op at the data layer. If it does not, plan for transparent rehash-on-successful-login: verify with the legacy path, re-hash with the new hasher, persist. Never require a password reset as the migration mechanism unless there is no alternative.

Compatibility. Pin the package to a range that matches the core framework version, and verify the Composer constraint graph resolves cleanly against the application's existing lockfile. Check that the runtime image provides the extensions the chosen algorithm needs before, not after, rollout.

Sequencing.

1. Security and provenance review: read the implementation, its tests, and the parent repo's advisory history.
2. Pin the version and record the rationale in the dependency register.
3. Wire container binding and configuration in a non-production environment.
4. Validate against known-answer test vectors and against a sample of real legacy hashes if migrating.
5. Implement rehash-on-login if required by step 4.
6. Roll to one service, observe, then standardize.

Operational Impact

Maintenance. Maintenance is effectively inherited from the Marko monorepo release train; this repo will not receive independent updates. Assign a named owner to track parent-project releases and advisories, because the split repo will not surface them prominently. Budget is small — this is a low-churn dependency — but it is not zero, and it is a security-sensitive one.

Support. MIT licensed, community-supported, no vendor SLA. Escalation runs through the monorepo's issue tracker, which means response times are outside the organization's control. For a credential-storage component, decide up front whether the internal risk tolerance permits that, or whether a maintained fork is warranted.

Scaling. Operationally negligible. Cost is CPU per authentication event, bounded by the configured work factor; it scales linearly with login volume and is trivially parallel. The only real capacity consideration is that deliberately expensive hashing can become a self-inflicted bottleneck under login storms or credential-stuffing attacks — that is a concern for the authentication layer's rate limiting, not for this package, but the two should be designed together.

Failure modes.

• Missing extension or unsupported algorithm in a runtime image causing exceptions on every hash or verify.
• Inconsistent parameter configuration across environments producing hashes that behave differently than tested.
• Rehash-on-login silently unimplemented, leaving weak legacy hashes in place indefinitely.
• Container binding collisions where the application already registers its own hasher.
• Algorithm swaps applied without a migration path, invalidating every stored credential.
• Upstream fixes delayed by the split-repo routing, leaving a known issue unpatched longer than the org's SLA allows.

Ramp-up. Low for application engineers — the surface is a handful of methods and most developers will touch it once. The real cost is concentrated in a security reviewer or senior engineer spending roughly half a day on provenance and implementation review. Organizationally, this is a one-time standards decision with a small recurring monitoring obligation, not a per-team learning investment.