Oc Pwnedpasswords Plugin Laravel Package

Product Decisions This Supports

• Security roadmap: Supports a low-effort control to block known-breached passwords at registration, reset, and password-change flows, reducing account-takeover risk.
• Build vs. buy: Justifies using a maintained integration instead of building and maintaining a custom Have IBeenPwned/Pwned Passwords client for a Winter CMS/October CMS application.
• Compliance and policy evidence: Helps demonstrate password hygiene controls for security reviews, customer questionnaires, and internal password-policy requirements.
• Vendor and platform standardization: The v2.0.0 rebrand to Winter.PwnedPasswords / winter/wn-pwnedpasswords-plugin signals alignment with the Winter namespace. PMs should treat this as a platform-consolidation decision, not a feature release.
• Migration planning: v2.0.0 is a breaking rename: namespace LukeTowers\PwnedPasswords → Winter\PwnedPasswords, Composer package luketowers/oc-pwnedpasswords-plugin → winter/wn-pwnedpasswords-plugin. Roadmaps should include dependency/import updates, deployment verification, and documentation changes. v1.1.2 and earlier retain the old names.

When to Consider This Package

• Consider it if the product runs on Winter CMS/October CMS and needs a drop-in breached-password check without owning the integration.
• Consider it when the team wants a small, focused security dependency and can accept an external Pwned Passwords API dependency and associated privacy/network review.
• Consider v2.0.0 specifically if the team can update Composer requirements, PHP namespaces/imports, deployment scripts, and internal documentation in the same release cycle.
• Look elsewhere if the application is a general Laravel app that can use Laravel’s native uncompromised-password validation and does not need CMS plugin integration.
• Look elsewhere if external API calls are prohibited, an enterprise SLA is required, or the team cannot absorb a breaking namespace/package rename. Existing users may temporarily pin v1.1.2 or earlier, but should track security updates and plan migration.

How to Pitch It (Stakeholders)

• Executives: This is a low-cost security control that reduces account-takeover risk by rejecting known-breached passwords. v2.0.0 is primarily a rebrand and namespace/package rename, so the business decision is whether to schedule the migration, not whether to adopt new functionality.
• Engineering: Update the Composer package from luketowers/oc-pwnedpasswords-plugin to winter/wn-pwnedpasswords-plugin and replace LukeTowers\PwnedPasswords references with Winter\PwnedPasswords. Test registration, reset, and password-change flows; update deployment docs and lockfiles. Release notes indicate the rename was already on main but unreleased, so v1.1.2 and earlier remain on old names.
• Security/compliance: Position the package as evidence of breached-password screening. Confirm API/privacy behavior and document the control in security questionnaires.
• Product/operations: Treat v2.0.0 as a planned breaking-change migration with an owner and timeline. Avoid surprise upgrades in production; communicate that there are no user-facing feature changes, but dependency and namespace updates are required.