Salt and cloud registration

Last updated: 6 Jul 2026

Salt lives in your vault database on each device—not on NT² servers.

Who this is for

Premium users enabling cloud sync who want to understand where the KDF salt lives and how new devices get the same salt without a server fetch API.

What you need


Tier	NT² Premium when re-registering existing cloud rows in production
Vault state	Unlocked to register on first sync enable
Network	Online for register on sync enable
Feature toggle	Cloud sync registration (automatic on enable)

Steps

Where salt is stored

	Local vault (all users)	Cloud sync (Premium)
Salt storage	Per-vault `vault_meta.saltHex` in local SQLite	Same — salt stays on the device
New device unlock	`.nt2backup`, recovery kit, or replica setup QR	Same OOB paths only
Master password on server	Never	Never

NT² does not expose GET /api/salt. Cross-device salt travels in the replica handoff QR, backup file, or recovery kit—not via the Workers API.

Register for cloud sync (first enable)

Open Settings → Vault & sync → Cloud sync and choose Enable cloud sync.
After Key DID authentication, registerUser sends only your public Key DID fields (identity bind). It does not upload KDF salt, password verifier, or encrypted Share_pw.
KDF still uses the salt already in local vault_meta on that device.

New device (replica handoff)

On Device A (locked OK), open Set up on another device and show the setup QR.
On Device B, scan the QR or open the link → enter master password on /link.
The QR carries salt + keyDid out-of-band; Device B writes them into local vault_meta.
When cloud sync was on for Device A, Device B runs auth + fullSync after confirm.

Tips and common mistakes

Salt is not secret — it slows offline guessing; security comes from your master password strength.
Cloud registration does not escrow private signing keys — threshold unlock uses local Shamir material.
Local-only vaults never call the cloud register API; recovery kit + backup remain sufficient.