- What does graham-campbell/passwd actually do?
- It is a thin password manager for Laravel 4.1 built on PHP's native password_hash and password_verify functions. It is split into hashers that produce a hash and checkers that verify one, potentially across multiple legacy formats. It also generates secure random passwords and can enforce strength rules such as requiring letters, numbers, and symbols. The package binds into Laravel's container through a service provider and exposes a Passwd facade.
- Is graham-campbell/passwd compatible with modern Laravel versions?
- No. The package targets Laravel 4.1, depends on illuminate components from that generation, and its last tag is v0.4.0-alpha. On any modern Laravel application you should use the built-in Hash facade instead, which wraps the same primitives and is actively maintained. The shipped integration is Laravel-specific despite any framework-agnostic claims in the description.
- How do I install graham-campbell/passwd in a Laravel 4.1 app?
- Run composer require with the exact pinned tag, for example graham-campbell/passwd:0.4.0-alpha, and never use a caret range on a pre-1.0 security-adjacent package. Then register the service provider and the Passwd facade in app/config/app.php, the Laravel 4.1 way, and publish or configure the package config file. Before committing, run a composer require dry-run against a throwaway branch to confirm it does not conflict with your illuminate constraints.
- Can it verify legacy or weaker password hash formats?
- Yes, that is the one genuinely differentiated use case. The checker layer can verify hashes in multiple formats, so it is useful for a one-time legacy backfill or an account-claim flow where you must accept hashes from an older CMS or forum. Use a verify-any, rehash-on-success pattern: try the legacy checker, and on success immediately rehash with the current hasher and persist. Gate the legacy path behind an import-time flag so you are not running multiple checkers on every login forever.
- Should I use this package instead of Laravel's Hash facade?
- In most cases no. Laravel's Hash facade already wraps password_hash and password_verify, and on any modern Laravel it is the correct choice. The only reasons to reach for this package are an existing Laravel 4.1 application with a specific hash format to verify, or a migration script that must accept legacy hashes. If the capability gap over Hash and password_* is none, stop and close the ticket.
- What are the security risks of using a pre-1.0 alpha package for passwords?
- The risk is concentrated in provenance rather than the code itself. The upstream lives under a deprecated namespace, has zero dependents, and only carries an alpha tag, which means no CVE patches, no PHP version compatibility fixes, and no issue-tracker support. The API is not a stable contract, so config keys and checker registration can shift between tags. Pin the exact tag and have a budget and owner for patching it yourself if needed.
- Does graham-campbell/passwd support Argon2 and bcrypt, and what are the pitfalls?
- It relies on PHP's native password hashing, so Argon2 availability depends on how PHP was compiled on your platform. Always check defined('PASSWORD_ARGON2I') before you set Argon2 as the default algorithm. Bcrypt also silently truncates passwords at 72 bytes, so validate or pre-hash long inputs if that matters for your policy. Have security review sign off on the default algorithm and cost parameters.
- How do I configure the default hashing algorithm and cost factors?
- Configuration lives in the package config file, where you select the default hasher and its cost parameters. Keep cost factors and rehash rules in a single place, such as a CredentialService or model mutator, so policy is enforced consistently. Avoid scattering algorithm choices across controllers, and document why a given cost was chosen for your platform. The source surface is small enough to read end to end in an afternoon, which makes auditing the configuration straightforward.
- How should I integrate it to avoid lock-in and make removal easy later?
- Wrap it before you wire it: define a single PasswordHasher interface with hash() and check() methods, bind one implementation in the container, and let application code depend on the interface rather than the Passwd facade. That costs roughly twenty minutes and reduces the blast radius of abandonment to one class and one binding. Prefer converting the dependency into a one-time backfill or account-claim script rather than a persistent login-path dependency. When the legacy flag is cleared, delete the dead checker.
- Is graham-campbell/passwd maintained, and what are the alternatives?
- It is effectively unmaintained: the upstream repository sits under a deprecated namespace with no dependents and an alpha release as its last tag. There is no external validation that anyone is running it in production, and it receives no security or compatibility updates. The alternatives are Laravel's Hash facade and PHP's native password_* functions on modern Laravel, or a short-lived in-house legacy verifier for a one-time migration. For a 4.1 stack, the real roadmap item is the platform retirement date, not this package.