trackslash
VAULT-23 P2

Add a duress vault that opens with an alternative app lock password

0
All issues

Description

Let people set a second, duress password for the app lock. Entering it opens a separate shadow vault instead of the real one. Someone coerced into unlocking the app can then show a convincing decoy. This needs the app lock password from VAULT-22.

This will probably need splitting into sub-issues.

Design (decided):

  • Setup: it lives inside the app lock password screen (VAULT-22). There's no separate Settings entry.
  • One action: the only thing on offer is a "make duress database" action. It sets a duress password and creates the shadow vault. If one already exists, it replaces it. There's no separate way to view, edit or remove it.
  • No sign it exists: once a duress vault is created, nothing in Settings shows that one exists. The app lock password screen and the action look identical whether or not one has been made, so the wording can't switch between "Create" and "Replace", for example.
  • Opening it: the only way in is to lock the app and enter the duress password at the next unlock. There's no in-app switch between vaults. To fill the shadow vault with decoy items, you unlock into it and add them there.

Rules from MANIFESTO.md to keep:

  • No way to tell the passwords apart (C2): at the lock screen, the real and duress passwords must behave identically: same timing, animation and haptics. Inside the shadow vault, nothing may give it away. It shows the same app lock password screen and the same action.
  • No telemetry (C3): no analytics, log line or crash data may record whether a duress vault exists or has been opened.
  • Device authentication (C4): Face ID or the passcode never decides which vault opens; the password does.
  • No audit log (C6): keep no record or history of duress unlocks.
  • Discoverability (C9): the action's label is still visible to anyone who opens the app lock password screen. Word it with C9 in mind. It never reveals whether a duress vault is set up, but it does tell a curious reader that the feature exists.

Still to decide:

  • What the action and the password change do when they're used from inside the shadow vault. They must behave plausibly without touching the real vault or its password.
  • What happens if someone tries to set the real and duress passwords to the same value.

Storage:

  • The shadow vault has its own store, with its own items, tags, killphrases and backup history.
  • The mere presence of a second store reveals the feature, so consider always creating it, even when no duress vault has been made.

Everything else that reads the vault:

Each of these must follow whichever vault is open, or be proven safe:

  • widgets
  • AutoFill
  • auto-backup
  • exports and device transfer
  • the Backups page's last-backup status

Auto-backup must never overwrite a real backup with the decoy. Backups made from either vault must not reveal that the other exists (C10).

Sub-issues

2
VAULT-51 P2 Encryption 12: add duress slots to the encrypted store Done VAULT-70 P2 Encryption 12b: keep backup settings per vault Done

Linked issues

3
Relates to VAULT-22 P2 Add an optional password to the app lock Done
Relates to VAULT-26 P2 Investigate encrypting the vault on device with the app lock password Done
Relates to VAULT-34 P2 Erase the vault after too many wrong app lock passwords Done

GitHub

0

No branches or pull requests linked.

Comments

2
Bradley

Fixed in https://github.com/badbundle/vault-app/pull/655 (merged as 24e67d49), which turns the App Lock Password, and with it the duress password, on in the shipping app. Earlier parts:

  • #648 (VAULT-51, merged as 78cd21ba): the duress slots.

  • #652 (merged as 28ce2e15): the Set Duress Password UI.

  • #651 (VAULT-70, merged as 2fd6d3b5): per-vault backup settings.

  • #653 (VAULT-34, merged as 86581f1b): the duress password resets the attempt count exactly as the real one does.

  • Setup: one "Set Duress Password" action on the App Lock Password screen. It looks the same whether or not a duress vault exists, and there's no way to view or remove one (C9). Setting it again replaces the duress vault. A duress password equal to the open vault's App Lock Password is refused.

  • Opening it: enter the duress password at the lock screen. Every vault is one of 16 equal slots in the same fixed-size file, and unlocking finishes at the same deadline, so the two passwords can't be told apart by timing, animation or haptics (C2). Device authentication never picks the vault (C4).

  • Inside the duress vault: the same App Lock Password screen and actions, acting only on that vault's own slot.

  • Everything else follows the open vault: backups, the backup password, auto-backup and the PDF hint are kept in each vault's own payload, so backups from either vault don't reveal the other (C10). Widgets, QuickType and AutoFill show nothing while the password is on.

  • No telemetry, logs or history of which vault opened (C3, C6).

Bradley

The UI is done in https://github.com/badbundle/vault-app/pull/652 (merged). The storage was done in VAULT-51 (#648).

The action: "Set Duress Password" sits on the App Lock Password sheet, under Change Password and Turn Off Password. It asks for device authentication first, then calls AppLockPasswordService.makeDuressVault(password:).

  • The explanation says entering the duress password instead of the App Lock Password opens a separate, empty vault, that you add items to it by unlocking with it, and that setting it again replaces the last one with a new, empty vault.
  • The password rules are the same as the App Lock Password's.
  • The confirmation always reads "Duress Password Set".

No sign one exists:

  • The row, screen and confirmation look identical whether or not a duress vault exists, and inside one. Snapshot tests hold all three cases to the same images.
  • There's no view, edit or remove, and nothing is logged.

Same passwords: only a password equal to the open vault's own is refused ("Must be different from your App Lock Password."). Anything else is accepted silently, per the design.

Still open under VAULT-23:

  • VAULT-70 (#651, in review): each vault keeps its own backup password, backup events, auto-backup and PDF hint.
  • Turning the feature on in the app (the VAULT-22 wiring PR). Until then, the service is gated off.

Everything else that reads the vault:

  • Widgets, AutoFill and QuickType are locked while a password is set (VAULT-49, #646).
  • Exports and device transfer read the open vault's store.
  • Auto-backup and the Backups page follow the open vault, which is VAULT-70.