decision: Argon2id runs at INTERACTIVE cost for the at-rest vault key #401

Open
opened 2026-09-21 20:37:56 +02:00 by clawbot · 0 comments
Collaborator

Severity: hardening. Owner decision.

Where. src/shared/vault.js:86-93 and 113-120 (crypto_pwhash with
OPSLIMIT_INTERACTIVE / MEMLIMIT_INTERACTIVE); src/popup/views/addWallet.js:116
(the 12-character minimum password).

The question. The profile is stored unencrypted in extension storage except
for wallets[].encryptedSecret, so the key-derivation cost and the password
policy are the only protection of a stolen profile. vault.js deliberately uses
INTERACTIVE (2 passes, 64 MiB, ~150 ms) because the password is entered on every
signature and a heavier cost would slow every signature. libsodium recommends
MODERATE (3 passes, 256 MiB) or SENSITIVE for data at rest.

Options.

  • Keep INTERACTIVE and record the reasoning in README Key Decisions (the
    per-signature UX cost is the reason).
  • Move to MODERATE (~0.5–1 s per signature) and re-encrypt each secret on the
    next successful unlock.

Recommendation. Document the current choice in README Key Decisions. A
per-signature password prompt is a real UX constraint that argues for
INTERACTIVE, and the 12-character minimum is the lever that matters more for a
stolen profile — so raising the minimum (and rejecting weak passwords) may be a
better return than the KDF cost.

Definition of done.

  • The owner rules keep vs raise the parameters.
  • If kept: README Key Decisions states the parameters and why (the
    per-signature cost).
  • If raised: the new parameters are set, existing secrets are re-encrypted on
    the next unlock, and the README is updated.

Model: fable-5-1 (review); opus-4-8 (filing)

Severity: hardening. Owner decision. **Where.** `src/shared/vault.js:86-93` and `113-120` (`crypto_pwhash` with `OPSLIMIT_INTERACTIVE` / `MEMLIMIT_INTERACTIVE`); `src/popup/views/addWallet.js:116` (the 12-character minimum password). **The question.** The profile is stored unencrypted in extension storage except for `wallets[].encryptedSecret`, so the key-derivation cost and the password policy are the only protection of a stolen profile. `vault.js` deliberately uses INTERACTIVE (2 passes, 64 MiB, ~150 ms) because the password is entered on every signature and a heavier cost would slow every signature. libsodium recommends MODERATE (3 passes, 256 MiB) or SENSITIVE for data at rest. **Options.** - Keep INTERACTIVE and record the reasoning in README Key Decisions (the per-signature UX cost is the reason). - Move to MODERATE (~0.5–1 s per signature) and re-encrypt each secret on the next successful unlock. **Recommendation.** Document the current choice in README Key Decisions. A per-signature password prompt is a real UX constraint that argues for INTERACTIVE, and the 12-character minimum is the lever that matters more for a stolen profile — so raising the minimum (and rejecting weak passwords) may be a better return than the KDF cost. **Definition of done.** - [ ] The owner rules keep vs raise the parameters. - [ ] If kept: README Key Decisions states the parameters and why (the per-signature cost). - [ ] If raised: the new parameters are set, existing secrets are re-encrypted on the next unlock, and the README is updated. Model: fable-5-1 (review); opus-4-8 (filing)
clawbot added this to the 1.0.0 milestone 2026-09-21 20:37:56 +02:00
sneak was assigned by clawbot 2026-09-21 20:37:56 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/AutistMask#401