Wp Password Bcrypt Laravel Package

Technical Evaluation

Architecture fit

• First, a scoping correction: roots/wp-password-bcrypt is a WordPress plugin, not a Laravel/PHP package in the Composer/library sense. It ships no service provider, no facades, no config publishing, and is not installable via composer require. It works by overriding WordPress's pluggable password functions (wp_hash_password, wp_check_password, wp_set_password) and storing hashes with a $wp$ prefix ahead of the standard bcrypt $2y$ payload.
• Consequence: if the consuming stack is Laravel or a standalone PHP application, this release is not applicable and should be closed as out-of-scope. There is no integration surface.
• If the consuming stack is WordPress (including Bedrock/Trellis-based Roots stacks, where this plugin is a common default), the fit is good but now time-boxed — see deprecation below.

Integration feasibility

• Drop-in install: wp plugin install / Composer via wpackagist / mu-plugin autoload. Low effort, no application code changes.
• 1.3.0 is a small, low-risk diff: signature alignment with WordPress 6.7's wp_set_password action, PHP 8.0+ floor, PHP 8.0–8.4 CI matrix, Dependabot, and #[\SensitiveParameter] on $password/$hash.
• The SensitiveParameter change is genuinely valuable: it prevents plaintext passwords and hashes from appearing in stack traces and error logs on PHP 8.2+. This is a security hygiene improvement, not a functional one (the attribute is inert on 8.0/8.1).

Technical risk

• Sunset / end-of-life (highest severity). PR #52 "Sunset package" is the headline of this release. A security-sensitive component that sits directly in the authentication path will no longer receive patches. 1.3.0 should be treated as the terminal version, adopted as a final frozen artifact rather than a maintained dependency.
• Breaking change for PHP 7.x estates. The floor rises to PHP >= 8.0. Any site on 7.4 cannot take 1.3.0 and will be stranded on 1.2.0 with no upgrade path.
• Removal hazard. Because hashes are stored with the plugin's $wp$ prefix, deactivating the plugin without a migration means WordPress core cannot verify existing credentials — effectively locking out every user. Any decommission plan must include hash re-verification/rehashing on next successful login, not a straight plugin deletion.
• Silent behavioural change risk is low: no change to the hashing algorithm, cost factor, or stored format in this release.

Key questions

1. Why was the package sunset — has WordPress core absorbed bcrypt/Argon2 support, or has Roots simply discontinued maintenance? The decommission strategy depends entirely on the answer.
2. Does the hosting provider/estate already require PHP >= 8.0? If not, what is the upgrade timeline?
3. Are there non-WordPress consumers of this codebase in our portfolio? If yes, they should be removed from scope.
4. What is the minimum WordPress version we support, and does it include 6.7 (the wp_set_password signature change)?
5. Is there a fork, community successor, or core-native path that provides a supported long-term replacement?

Integration Approach

Stack fit

• WordPress only. Bedrock/Trellis/Roots stacks are the natural home; the plugin is already idiomatic there and typically pulled via wpackagist-plugin/wp-password-bcrypt.
• Laravel/standalone PHP stacks: no fit. Do not attempt to bolt this on — Laravel's Hash facade already provides bcrypt/Argon2id with SensitiveParameter-aware exception handling. If the query is "should our Laravel app adopt this?", the answer is no, and the assessment should be closed.

Migration path

• 1.2.0 → 1.3.0 is a non-breaking upgrade only if the runtime is PHP >= 8.0. No data migration, no rehash, no re-login required.
• Pin the version explicitly (1.3.0, not ^1.3) since there will be no 1.3.1. Treat it as a vendored artifact.
• For PHP 7.4 sites: do not upgrade; instead prioritise the PHP 8.x upgrade as a prerequisite project. Leaving them on 1.2.0 is acceptable only as a short-dated exception, and they remain outside the security-patch envelope either way.
• Long-term exit path: verify whether the target WordPress version handles the stored hash format natively; if not, plan a rehash-on-login migration before deactivation.

Compatibility

• PHP 8.0–8.4 explicitly tested; 8.4 support matters because it is the current release line.
• WordPress 6.7 signature alignment fixes an ArgumentCountError/parameter-mismatch class of bug for callbacks hooked to wp_set_password — relevant if we have custom code on that action (common in password-reset notification and audit-logging plugins).
• Multisite: verify, as wp_set_password behaves differently per-site vs network.

Sequencing

1. Inventory: enumerate every WordPress property running this plugin and its PHP version.
2. Upgrade PHP 7.4 properties to 8.1+ (prerequisite, likely the longest lead item).
3. Roll 1.3.0 to a canary site; exercise login, password reset, and any wp_set_password hooks.
4. Roll to remaining fleet; pin the version in the lockfile.
5. Open a separate track for the sunset exit strategy (core-native verification or documented frozen-dependency risk acceptance).

Operational Impact

Maintenance

• Effectively zero ongoing maintenance cost — but also zero vendor maintenance. The burden shifts to us: we own the security posture of this component from 1.3.0 onward.
• Dependabot config in the repo is now moot; no further releases are expected. Remove it from dependency-update automation and add it to an exceptions/EOL register so it stops generating noise or false "up to date" signals.

Support

• No upstream support channel going forward. Issues and PRs are unlikely to be triaged.
• Internal runbook needed: what to do if a bcrypt vulnerability or PHP incompatibility (e.g. PHP 9.0) surfaces. Document the fork-and-patch contingency — the codebase is small enough that forking is realistic, which materially lowers this risk.

Scaling

• Negligible. Bcrypt hashing is per-login, not per-request. Cost factor (default 10) is unchanged in this release, so authentication latency is unchanged.
• No horizontal-scaling concerns; no external services, no cache, no state.

Failure modes

• Total authentication outage on removal — the $wp$ prefix means core cannot verify hashes if the plugin is deactivated. Highest-impact failure mode; must be gated behind a tested rehash migration.
• Silent upgrade block on PHP 7.4 — Composer/plugin update simply refuses, leaving sites on an older security posture without an obvious alarm. Add explicit monitoring.
• Hook signature mismatch — third-party code hooked to wp_set_password expecting the pre-6.7 signature. Low likelihood, but worth a smoke test on password-reset flows.
• Credential leakage in logs — mitigated by SensitiveParameter, but only on PHP 8.2+. On 8.0/8.1 the exposure remains; if that matters, the argument is for pushing to 8.2+ rather than staying on 8.0.

Ramp-up

• Minimal. A WordPress-fluent engineer can read the entire plugin in under an hour; it is a handful of functions plus a hash-prefix helper.
• The real ramp-up cost is institutional, not technical: making sure the sunset status and the "do not deactivate without rehash" rule are captured somewhere durable, and that future engineers encountering a $wp$-prefixed hash in the database know why it is there. Add that to the platform documentation while the context is fresh.
• For a Laravel-focused team, ramp-up is not applicable — the correct action is to close out this assessment as out-of-scope rather than invest in context that will never be used.

Recommendation: Upgrade WordPress properties on PHP >= 8.0 to 1.3.0 as the terminal pinned version, capture the EOL decision and the hash-migration constraint in the platform runbook, and open a follow-up to evaluate a core-native or forked replacement. Reject for any Laravel/non-WordPress PHP estate.