The KDF salt stays on your device

Claim: unlock material belongs with the vault

NT² Vault does not ask a server for permission to unlock your local data.

The material used by the password-based key derivation path stays with the local vault profile: a unique salt, the parameters for PBKDF2, and a password verifier. Your master password is entered on your device. Web Crypto performs the derivation there. The resulting key material is used there. No unlock request needs to carry the password, its derivative, or the salt to the edge.

That boundary is easy to describe and surprisingly easy to erode. A product can encrypt every record before upload and still make its servers important to unlock. It can keep the salt in an account database, expose a salt lookup endpoint, or place password-checkable recovery material next to encrypted copies. The payloads may remain ciphertext, but the provider has accumulated the ingredients for testing password guesses.

We chose a harder line: the cloud is not part of the local unlock protocol.

This does not mean the salt is confidential. Cryptographic salts are normally stored in the clear. Their job is to make identical passwords derive different keys for different vaults and to defeat one precomputed table from working across many users. The important question is not whether an attacker may ever learn one salt. It is whether compromising one central service gives the attacker a catalog of salts plus enough password-checkable material to run quiet, unlimited guesses against many accounts.

NT² declines to build that catalog.

Constraint: cloud recovery can become a password oracle

Password-based encryption has an unavoidable property: if an attacker obtains the right inputs and a reliable success signal, guesses can be tested offline. The attacker does not need to keep contacting the real application. Rate limits, alerts, IP blocking, and account lockouts no longer matter. The loop runs on hardware the attacker controls:

1. Take a candidate password.
2. Run the configured KDF with the vault's salt.
3. Try to authenticate known ciphertext or a verifier.
4. Keep the candidate when authentication succeeds.

PBKDF2 makes each attempt more expensive. NT² uses PBKDF2 with SHA-256 and 100,000 iterations for the password-based derivation path. That cost matters: it slows down every guess and prevents the raw password from being used directly as an encryption key. A unique 16-byte random salt prevents attackers from amortizing one precomputed result across vaults.

But PBKDF2 does not make weak passwords strong, and it cannot restore an online rate limit after the inputs have been copied. Once an attacker can test guesses locally, the defender's server is out of the loop.

That is why the phrase “the salt is public anyway” is incomplete. Salt secrecy is not the goal. Avoiding centralized, password-checkable bundles is the goal. A salt alone is not a verifier. A verifier alone should not be useful without the derivation inputs. Yet a recovery service naturally wants to gather both, along with wrapped keys or ciphertext, because those are exactly the things it needs to promise convenient restoration.

This is the recovery-desk fantasy: support can always get you back in, while somehow remaining cryptographically incapable of helping anyone else get in. Those goals conflict when recovery depends on server-held password material. If the service can identify your vault, supply its KDF inputs, and decide whether a password-derived key is correct, then the service—or an attacker who copies its database—has an oracle.

Calling the database “escrow” does not change its security properties.

The safest central password database is the one we do not create. Optional cloud features can relay encrypted replicas, coordinate synchronization, and bind an account to a public cryptographic identity. They do not need to participate in password derivation.

Design: local salt, local verifier, cryptographic cloud identity

When a vault is created, the device generates a fresh random salt with crypto.getRandomValues(). That salt is stored in the vault's local profile storage, alongside the metadata needed to unlock that particular vault. It is not uploaded during cloud registration.

The browser imports the master password as PBKDF2 input material and asks Web Crypto to derive a 256-bit key using PBKDF2-SHA-256 with 100,000 iterations. For current vaults, this password-derived key acts as a key-encryption key: it opens the password-protected unlock factor. The operational vault key is reconstructed locally from the required factors. Older vault formats can use the password-derived AES key more directly. In both cases, the KDF boundary is the same: password, salt, derived material, and unlock attempt stay on the device.

The operational AES-GCM CryptoKey is created as non-extractable. JavaScript can ask Web Crypto to use that key for permitted operations, but cannot call exportKey() to recover its raw bytes. Non-extractable does not make a compromised page harmless—malicious code running in an unlocked session could still request operations or read displayed plaintext—but it removes an easy key-export path and narrows what can be stolen for later use.

Why keep a password verifier?

AES-GCM provides authenticated encryption. Decryption either validates the authentication tag or fails. NT² uses that property for a small local password verifier: known plaintext is encrypted under a password-derived key with a fresh initialization vector, and the resulting ciphertext is kept in local vault storage.

On unlock, the device derives the candidate key and attempts to authenticate the verifier. A successful result means the password-derived key is correct. A failure becomes a clear “wrong password or damaged data” result instead of letting the application continue with a bad key and fail later in confusing ways.

The verifier is not a password hash, a copy of the master password, or a secret answer sent to support. It is deliberately password-checkable ciphertext. That is precisely why it must not sit in a central account table next to every user's KDF salt.

Every AES-GCM encryption also requires a unique IV for a given key. The verifier gets its own random IV, as do other encryption operations. Reusing an IV under the same AES-GCM key can destroy confidentiality and authenticity; a local-only design does not relax that rule.

What the edge receives instead

Cloud registration binds a vault to a cryptographic identity. The device sends the public material needed for challenge-response authentication. To prove control later, the unlocked client signs a fresh challenge with its private signing key. The edge verifies the signature using the registered public key.

That identity is not an email address and is not derived from the master password. Password changes do not need to rename the cloud account. Billing email, when present for receipts, is not an unlock identifier. Most importantly, cloud registration does not need the KDF salt, password verifier, password-protected unlock factor, or plaintext private key.

The split is deliberate:

• Local profile storage holds the salt and password-checkable verifier.
• Device memory holds unwrapped keys only while the vault is unlocked.
• The edge holds public identity material and optional encrypted replica data.

Local unlock therefore works offline. A network outage cannot stop the browser from opening a vault already present on the device. A compromised edge account database does not hand an attacker the server-side half of a password reset workflow, because that workflow does not exist.

Moving a vault to another device requires moving the necessary local material through an explicit user-controlled path. An encrypted backup can carry the portable vault profile. A device-linking ceremony can transfer what the new replica needs. The cloud does not silently reconstitute unlock state from an email address.

Trade-off: we cannot replace what you lose

This design removes a capability that many people expect from online products. If you lose the only device containing the vault and also lose every usable backup or recovery factor, NT² cannot restore access.

There is no hidden copy of the salt waiting in an operations database. There is no support-only master key. There is no administrator command that converts a billing record into an unlock token. Support can explain backup and recovery options, but it cannot manufacture cryptographic material that was never sent to us.

That outcome is severe, so the product has to make ownership operational rather than rhetorical. Backups must be exportable. Recovery material must be presented clearly. Device migration must not depend on remembering an obscure cloud account procedure. Warnings about losing the last copy need to be direct, not buried in a settings panel.

The trade-off is not “security versus usability” in the abstract. It is a specific exchange:

• You lose provider-operated password reset.
• The provider loses a centralized password-guessing surface and the power to unlock your vault.
• You gain an offline vault whose continued accessibility depends on copies you control.

That responsibility will not suit everyone. Pretending otherwise would be bad security communication. NT² is for people who prefer a real custody boundary, with the corresponding need to maintain recovery paths.

What we refuse

We will not add a “forgot password” email that resets the master password. Email can prove access to an inbox; it cannot recreate a key that was derived and used only on a device. Making email sufficient would require a second unlock authority, and that would change the threat model for every vault.

We will not add a server endpoint that returns a KDF salt during unlock. Local unlock reads the local vault profile. A new device must be enrolled through a user-controlled backup, recovery, or handoff path—not by asking the edge for password-derivation ingredients.

We will not call server-held password material “zero-knowledge” merely because the payload database contains ciphertext. Zero-knowledge is a system property. It includes registration, recovery, synchronization, support tooling, and the failure modes after a breach.

And we will not promise that support can recover data we are designed to be unable to read. That promise would either be false or evidence of a back door.

Close: inconvenience as evidence

The local KDF salt is a small implementation detail with a large consequence: the edge cannot become a required participant in unlocking. Paired with a local verifier, on-device Web Crypto, and cryptographic cloud identity, it keeps the password boundary where the vault lives.

This is one concrete expression of what Null Trust² means: trust is reduced by removing powers, not by writing stronger assurances. It also makes a portable backup an essential part of ownership — the escape hatch is a file you hold, not a password reset we pretend to offer.

If that custody model matches what you want from a vault, you can open NT² Vault and keep the unlock boundary on your device.