A new password hasher needs an old-password path

Changing a password hashing algorithm is a migration of existing accounts. The new algorithm needs a path for verifying old hashes, upgrading them after a successful login and dealing with accounts whose owners never return. Without those decisions, a configuration change can leave a product with incompatible credentials or an indefinitely retained legacy verifier.

Looking back from November 2026, the Rails development digest of 31 October 2025 described an algorithm interface for has_secure_password. The 7 November digest described algorithm selection and built-in Argon2 support. These posts report development changes. Their presence alongside stable-release news does not establish that the hashing feature shipped in Rails 8.1.

Separate a development capability from a released API

The October interface named operations for algorithm identity, hashing, verification, salt and validation. November's post showed how Argon2 support built on that work. Together they motivate a migration design, but they are insufficient evidence for application code against a particular stable release. Before implementing anything, verify the exact stable version's documentation and source against the application's resolved dependencies.

This article deliberately includes no Rails implementation recipe. No current stable API is asserted here, and no password operation was performed. The argument concerns requirements that remain relevant whichever supported API eventually provides them. A product should establish its release boundary before copying syntax from an announcement or from moving development documentation.

Separate the desired algorithm from the library adapter as well. An adapter can expose a hashing function while the application still lacks compatibility with existing credentials. The release assessment must establish both the algorithm's availability and the behavior needed by the migration. A successful new-account signup tests only the newly written credential path.

Old credentials require old-hash verification

A stored password hash cannot ordinarily be converted into a hash of the original password under a different algorithm without obtaining that password again. That is why an automatic database rewrite is an unsuitable model for this migration. Successful authentication supplies a point at which the application has verified the presented password and can create a replacement digest under the chosen policy.

Design the transitional reader to identify and verify the credential format actually stored for each account. Do not merely switch the writer and assume every old row matches the new expectation. An unknown format should have an explicit failure or recovery path. Treat its identification rules as part of the credential contract, with enough precision to prevent accidental selection of the wrong verifier.

Preserve the successful-login condition. An unsuccessful password attempt must not replace the account's digest. A rehash should follow verified authentication and use the intended current parameters. This sequence is a proposed migration requirement, not a claim that a Rails helper performs every step automatically. Confirm the behavior of the selected implementation before relying on it.

Concurrency can affect the write. An account may change its password while another request is authenticating with the previous digest. The migration must not overwrite a newer credential merely because an older login finished later. Choose an update condition that respects the current credential state, and verify it through the application's actual persistence path when implementing the change.

A longer accepted password changes the input contract

The November post contrasts BCrypt's 72-byte restriction with Argon2's lack of that algorithm limit. Do not turn that comparison into a promise that an application should accept unlimited input. Request-size limits and computational cost remain product responsibilities. Preserve a deliberate input policy and consider encoded bytes as well as the number of visible characters.

Existing credential behavior also matters. A migration should not silently invent a different interpretation of passwords previously accepted by the old system. Establish the historical validation and verification rules before defining the transition. Test relevant boundary cases in the implementation's safe test environment, rather than inferring them from the new algorithm's capabilities alone.

Cost parameters need an operational decision. Password verification is work performed on authentication requests, so choose settings the service can sustain under its permitted load and abuse controls. A stronger algorithm name alone cannot establish safe capacity. No cost setting, benchmark result or recommended numeric parameter is claimed for a reader's infrastructure here.

Accounts that never return need an explicit policy

Opportunistic rehashing progresses only when people authenticate successfully. Accounts that remain inactive do not migrate through that path. Decide whether legacy credentials remain usable for a defined interval, become subject to reset at the next login or are handled under an account-retention policy. The owner must choose the condition for retiring the old verifier.

Keep that decision distinct from password deletion or account closure. A product may need to preserve business records while requiring credential recovery before access. Record the user-facing consequence and the support process. A recovery route must be usable by the intended account owner without weakening the identity checks that protect the account.

Avoid logging passwords or digests to measure progress. Aggregate counts by credential format may support migration tracking without copying credential material into operational reports. Define who can inspect the counts and how they relate to the deployed version. Progress should be explained as observed migration state, never an invented completion percentage.

A forced reset can be the simpler choice

The strongest counterargument is that maintaining two verifiers adds complexity. A narrow product with a reliable recovery path may reasonably require everyone to reset passwords, particularly when the old credential state cannot be trusted. That can give the migration a clearer end and avoid prolonged support for the previous format.

The cost falls on users and support. A forced reset can interrupt legitimate access, especially for accounts with stale recovery details. Compare that cost with the complexity and duration of staged migration. Neither approach is universally preferable. The choice should follow the product's threat assumptions and recovery evidence, rather than enthusiasm for a newly announced algorithm.

For software maintenance, request a plan covering the verified stable API, old-format authentication, successful-login replacement and inactive-account policy. Keep rollback compatibility with credentials already written by the new version in the release decision. The migration is complete when the intended accounts and remaining verifier obligations have an explicit, verified state.