Password Hashing for Vibe Coders

Direct answer: Store passwords with a maintained password-hashing library, preferably Argon2id for a new system where it is available. Give every password a unique salt, measure a work factor that fits your production environment, and store the library’s encoded verifier. Keep a migration path so successful logins can replace older or weaker verifiers.

A password database should contain values that let the server check a guess without recovering the original password. Plaintext, reversible encryption, and fast general-purpose hashes do not provide that boundary.

The vibe coding security guide places password storage inside authentication. Reset tokens, session behavior, and authorization remain separate controls even when the verifier is strong.

The vulnerable pattern: a fast hash

Vulnerable pattern. Never store real passwords this way.

const verifier = sha256(password)
await db.user.update({
  where: { id: user.id },
  data: { passwordHash: verifier },
})

SHA-256 is designed to be fast. That is useful for file integrity and random-token lookup, but harmful for human passwords. If an attacker obtains the verifier database, fast guesses are cheap. Identical passwords also produce identical hashes when no unique salt is used.

Reversible encryption changes the problem, not the outcome. Anyone who obtains the database and decryption key can recover every password. Authentication does not need plaintext recovery.

Why generated code chooses the wrong primitive

AI coding tools often recognize that plaintext is bad and reach for a familiar hash function. The name contains “hash,” the code is short, and the output fits a database column. The model may not distinguish a general digest from an adaptive password verifier.

Generated snippets may copy a fixed cost parameter without measuring it on the deployed hardware. A value suitable for a laptop may overload a small server under login traffic or be too cheap on modern hardware. One universal number ages badly.

Library output can also be mishandled. A generator may create a separate salt but forget to store it, truncate the encoded verifier, compare strings incorrectly, or hash an already encoded value a second time.

Use a maintained password-hashing library

OWASP’s current Password Storage Cheat Sheet recommends Argon2id for new applications where available. Argon2id is memory hard, which makes each guess consume both computation and memory. RFC 9106 defines Argon2 and its parameter model.

Use a well-maintained binding from the platform ecosystem rather than implementing Argon2 yourself. The high-level API should generate a salt, encode algorithm and parameters, and verify without application code parsing the internals.

const verifier = await passwordHasher.hash(password, currentPolicy)
await db.user.update({
  where: { id: user.id },
  data: { passwordVerifier: verifier },
})

During login:

const valid = await passwordHasher.verify(user.passwordVerifier, password)
if (!valid) throw new InvalidCredentialsError()

if (passwordHasher.needsRehash(user.passwordVerifier, currentPolicy)) {
  const upgraded = await passwordHasher.hash(password, currentPolicy)
  await replaceVerifier(user.id, user.passwordVerifier, upgraded)
}

The comparison and replacement should use library functions. The conditional replacement prevents two simultaneous logins from overwriting an independently changed password.

Calibrate the work policy

Argon2id has memory, iteration, and parallelism parameters. Measure candidate settings on the slowest production class that will verify passwords. Include expected login concurrency, autoscaling behavior, memory limits, and denial-of-service controls.

Aim for a cost that makes offline guessing expensive without making normal authentication unreliable. Record the chosen algorithm, library version, parameters, benchmark environment, and review date. Revisit them as hardware and deployment constraints change.

Do not present the current OWASP baseline as a timeless constant. It is useful starting guidance, while the deployed service still needs measurement. NIST SP 800-63B-4 requires an approved password hashing scheme and a suitable cost factor but does not prescribe OWASP’s exact Argon2id parameters for every service.

Scrypt is a memory-hard alternative when Argon2id is unavailable. Bcrypt and PBKDF2 may remain necessary for legacy or compliance settings. Understand their constraints and follow current authoritative guidance for the chosen implementation.

Salts, peppers, and database fields

Every password needs a unique random salt. Modern libraries normally include it in the encoded verifier, alongside the algorithm and work parameters. The salt is not secret and can live in the same database field.

A pepper is optional secret key material shared outside the password database, often through a secrets manager or hardware-backed service. It can add a layer if the database leaks without the pepper. It also creates operational risk: losing it can lock out every account, and rotating it may require all users to authenticate or reset passwords. Do not add a pepper without a recovery and rotation plan.

Size the database column for the complete encoded verifier. Do not assume every algorithm has the same length. Keep an algorithm/version marker if the library format does not already carry one.

Never log passwords, verifier values, or library comparison errors that include either value. Redact request bodies at ingress and application logging layers.

Migrate old verifiers without exposing passwords

Do not decrypt or batch-convert verifiers. A one-way hash cannot be transformed into Argon2id without the user’s password. Upgrade after a successful old-algorithm verification, while the password is already present in server memory.

Keep a narrow verifier dispatcher for supported legacy formats. It should identify the format from trusted stored metadata, verify with the corresponding library, and immediately replace a successful legacy verifier with the current format.

Set a retirement plan. Dormant accounts may never log in, so a deadline can require a password reset for remaining old formats. Track counts by algorithm without exposing individual verifier material.

If an old database stored plaintext or reversible passwords, treat that as sensitive exposure. Move to a password-specific verifier, restrict access, rotate related credentials where needed, and follow the incident process. Do not preserve plaintext as a fallback.

Safe local verification

Use synthetic passwords in a test environment. Confirm:

1. Two accounts with the same password receive different encoded verifiers.
2. The correct password verifies and a wrong one returns the same public error as an unknown account.
3. A truncated or malformed verifier fails safely without exposing parser details.
4. A legacy verifier upgrades after one successful login.
5. A current verifier does not change on every login.
6. Concurrent login and password-change paths cannot restore an old verifier.
7. Production-like load stays within the documented latency and memory budget.
8. Logs, traces, errors, and analytics contain no password or verifier.

Benchmark on dedicated test inputs. Never copy production hashes into a developer tool or performance suite.

Edge cases that affect the boundary

Some bcrypt implementations ignore input after a byte limit. Password length in characters and bytes can differ under Unicode. Let the maintained library define its supported input and enforce a documented maximum before expensive hashing to control resource use.

Normalize only when the product’s password policy explicitly defines it. Silent changes can make a password impossible to reproduce across clients. NIST guidance should be read with the application’s Unicode handling and authenticator design.

Provider-managed authentication changes ownership of the verifier, not the need for review. Confirm which provider stores passwords, which settings you control, how migration works, and what evidence the provider exposes.

The related password reset and email verification guide covers how a new password reaches this hashing boundary through a single-use recovery flow.

What automation can and cannot prove

The browser-local AI app security checklist can prompt a team to document its algorithm, migration plan, and review date. It never accepts or tests passwords.

Static analysis can flag plaintext fields, general hash functions, or obsolete library calls. Unit tests can verify known formats. Neither proves that production work factors fit real hardware, secrets are absent from every log, or a managed identity provider follows the assumed configuration.

Sources

• OWASP: Password Storage Cheat Sheet
• IRTF RFC 9106: Argon2
• NIST SP 800-63B-4: Authentication and Authenticator Management
• NIST SP 800-132: Password-Based Key Derivation