Skip to content

Reject empty passphrases at the Vault::create boundary #287

Description

@forkwright

Finding

Vault initialization accepts an empty passphrase. The CLI confirmation path checks only that the two entries match, and the library boundary derives and stores a vault key for any byte slice, including zero bytes.

Evidence

crates/akroasis/src/vault/mod.rs:126-135 reads two passphrases and rejects only inequality; two empty inputs return Ok(first).

crates/kryphos/src/storage.rs:135-147 passes passphrase directly to crypto::derive_key and persists an encrypted known-plaintext key check without validating the input. crypto.rs:46-58 calls argon2 0.5.3's hash_password_into; that implementation rejects only passwords longer than MAX_PWD_LEN and accepts a zero-length password.

No test asserts rejection of an empty passphrase.

Why this matters

A vault initialized with no passphrase has no password entropy. Anyone who obtains the header's salt and key-check value can derive the exact master key immediately, regardless of Argon2's work factor. Because initialization succeeds normally, an accidental double-Enter creates a vault that appears protected but is not.

Desired correction

Enforce the invariant in Vault::create, not only in the interactive CLI, so every caller rejects empty input. Mirror the error early in the CLI with a clear retry message. Any stronger passphrase-quality policy should be explicit and separately specified; the non-empty invariant is the minimum safe boundary.

Done when Vault::create(path, b"") returns a typed validation error without creating filesystem state, the CLI refuses two empty entries, and regression tests cover both paths.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions