fix: verify passwords server-side instead of running argon2 in the browser

[MattDHill]

Summary

On mobile, entering the master password when creating a backup froze the whole browser for 20–25 seconds — long enough to read as a device crash. Same on Change Password. It was not tuiAutoFocus; it was argon2.

The UI called verify() from @start9labs/argon2 — a synchronous WASM Argon2id hash on the main thread — in three places: backup create, backup restore, and change password. StartOS hashes the master password with argon2::Config::rfc9106_low_mem() = Argon2id, 64 MiB, t=3, p=1, so that's ~192 MiB of memory-hard mixing, single-threaded, with the main thread blocked throughout. It can't be made fast client-side: the shipped WASM is already an optimized 45 KB release build, p=1 rules out threading, and SIMD would only buy 2–4×.

Worse, creating a backup onto a target whose existing backup used a different password ran it three times (master hash → target hash → original password), and Change Password ran it even when a cheaper validation had already failed — so mistyping the confirmation field cost you 20–25s before being told the passwords don't match. None of this reproduces against the mock server, whose fixture hash is m=1024,t=1.

The server already did the identical check on every one of these calls, natively, in milliseconds:

Client-side verify	Server-side equivalent
Create → master password	backup_all → check_password, before the backup task spawns (backup_bulk.rs)
Create → target's existing-backup password	BackupMountGuard::mount → load_metadata → check_password (disk/mount/backup.rs)
Restore → backup password	same mount path, via getBackupInfo (backup/target/mod.rs)
Change Password → current password	reset_password_impl → argon2::verify_encoded (auth.rs)

So all four client-side verifies are deleted and @start9labs/argon2 is dropped from the web entirely (dependency, wasm asset, and the initArgon() bootstrap — which the setup-wizard ran on every boot despite never calling verify()).

The one thing that needed a backend change

backup_all runs two password checks and both returned ErrorKind::IncorrectPassword, so the client couldn't tell "you typed your master password wrong" from "this target's existing backup was encrypted with a different password — ask for the original". Added ErrorKind::BackupPasswordMismatch (81) for the mount failure, which reaches the client as the RPC error code. ErrorKind has no TS derive, so no binding regeneration was needed.

Prompt semantics are preserved exactly: a password the server rejects leaves the prompt open to retry (previously verifyPassword's EMPTY + take(1); now TaskService.run's Promise<boolean> + filter(Boolean) + take(1) — note PromptModal.submit() calls next(), not complete(), so the take(1) is what closes the dialog).

Also in this PR

• tuiAutoFocus removed from every site — the shared prompt dialog, the refresh alert, the OS-update dialog, the marketplace package drawer, the setup wizard's password page, three StartTunnel dialogs, and StartWRT's inbound-rule dialog. On mobile it raised the keyboard the instant a sheet opened, over the dialog's own buttons.
• Ad-hoc password prompts are no longer form submissions. The shared prompt dialog sets autocapitalize="off" (mobile keyboards were capitalizing the first character of the backup password) and submits via its own buttons / Enter rather than a <form> submit, so browser password managers stop offering to save a backup encryption password as a saved credential. The setup wizard's Unlock Backup prompt gets the same autocapitalize treatment.

Notes

• The parked portal/routes/backups/ tree (@TODO 041, scheduled backup jobs) is kept — only its argon2 call is stripped, so un-parking it in 0.4.1 doesn't silently reintroduce the freeze.
• Verified: npm run check (all projects) + check:tunnel, and successful builds of ui, setup-wizard, tunnel, wrt, and brochure. Rust is left to CI.
• Unrelated, noticed in passing: check:tunnel is defined in package.json but missing from the aggregate check script, so npm run check never typechecks the StartTunnel web app. It passes clean today; not fixed here.

🤖 Generated with Claude Code

[dr-bonez]

Ideally we shouldn't return the hash to the frontend in the first place if we're doing this

[MattDHill]

Agreed — done in de0c3b0. And it was worse than just the hash:

• serverInfo.passwordHash — the master password's argon2 hash, sitting in the public db, so it replicated to every authenticated client. Field dropped; the real hash stays in the private db.
• StartOsRecoveryInfo.wrappedKey — shipped alongside the backup's passwordHash by getBackupTargets / setup.cifs.verify / the disk listing. That's the backup's encryption key sealed under the password, so a client holding both could crack the hash offline and then unwrap the actual backup key.

Two things that weren't obvious going in:

StartOsRecoveryInfo couldn't just get skip_serializing. The same struct is written back to the backup drive as unencrypted-metadata.json, so skipping those fields would have blanked the hash and wrapped key on disk and made existing backups undecryptable. Split instead: on-disk BackupUnencryptedMetadata keeps the key material and never leaves the server; the ts-exported StartOsRecoveryInfo is now just hostname/version/timestamp, with recovery_info mapping between them.

No migration needed. Current::pre_init round-trips the db through the typed Database model on every boot (both the Equal and Less branches), and with no deny_unknown_fields that drops the removed key from existing databases on next start — including boxes already on beta.10. I also removed the now-dead passwordHash write from the v0_3_6_alpha_0 migration so it never lands in the public db even transiently.

One thing to flag: I couldn't compile Rust locally on this machine, so the start-core changes and the two regenerated binding files are riding on CI. start-core-ts-bindings-check regenerates and diffs, so a green Generated Artifacts job is the proof those bindings are byte-for-byte what ts-rs emits — worth a look before merge.

[dr-bonez]

This seems unrelated

[dr-bonez]

Same here