A database whose salt is a password verifier is no longer opened without being asked

[dmitrat]

Item 2 of Docs/FIX-PLAN-FROM-SITE-FINDINGS-2026-08-15.md. This is a breaking change and belongs in 14.0.0.

What was happening

A database written before the crypto preamble kept opening under the old encryptor, and the code knew: WrapEncrypted's own remarks said its salt is a function of its password and its nonce counter restarts on every open. Nothing told anybody.

What is wrong with such a file cannot be repaired by opening it — 13.0.0 measured all three:

E1	the salt is SHA256(password + "_WitDB_Salt"), so one password means one key across every database ever created with it
E2	that salt is the file's first eight bytes, in the clear — the head of the file is a password verifier costing one SHA-256 against 5.6 hours through PBKDF2
E4	the nonce counter is set to zero in a constructor that runs on open, so two sessions encrypt different plaintext under one nonce, which AES-GCM has no recovery from

What changes

Both sites refuse — the paged store's Shape.Other and the LSM store's directory of SSTables with no header — and the message names what happened and both ways forward, in the order somebody would try them:

…this version will not open it: its salt is derived from the password and stored in the clear, and its nonce counter restarts on every open. Both are properties of the bytes on disk and cannot be repaired by reading them. Either open it with the version of WitDatabase that wrote it, or convert it by changing its password — which rewrites it into the current format. To read it as it is, ask for the old scheme by name: WithLegacyEncryption() on the builder, or 'Legacy Encryption=true' in a connection string.

The opt-in is part of the fix rather than a concession. "Or convert it" is impossible if nothing can read the source. It selects the old scheme and nothing else — a wrong password is still refused.

This reverses a promise 13.0.0 made, and that is the part to read twice

13.0.0 committed fixtures written by 12.8.0 — a paged database, a Fast Encryption one, and an LSM directory generated from a worktree at the parent commit — and three tests asserting that they still open.

Those three now carry the opt-in and go on proving the half that matters to somebody holding such a file: the data is still reachable, which is what makes converting it possible at all. The compatibility claim became conditional; it was not withdrawn.

The guards

The fixtures are those 12.8.0 files rather than anything synthetic — a fixture rewritten by the new code is a fixture that tests nothing.

sabotage	red
the paged refusal removed	APagedDatabaseFromBeforeThePreambleIsRefusedTest
the LSM refusal removed	AnLsmDirectoryFromBeforeTheHeaderIsRefusedTest
the opt-in never read	six cases, including all four compatibility ones

Two controls decide whether the refusal is narrow enough, and both had to be invented rather than found:

• a database written by this version opens with no opt-in — the refusal is about the old scheme, not about encryption;
• an unencrypted database is untouched. This matters more than it looks: an unencrypted file looks exactly like a legacy one to CryptoPreamble.Inspect, both being "page 0 is neither a preamble nor zeros". The branch is only reached when encryption was asked for, and now a case says so.

What is not in this PR

Studio has no affordance for it yet. A user who opens a legacy database in Studio will see the refusal message; the way through is the Open dialog's Connection string… button, which takes Legacy Encryption=true, and then Password… to convert. A proper affordance — recognise the refusal, explain it, offer the conversion — is Studio work and is named in the plan rather than left to be discovered.

And the release note. Whoever cuts 14.0.0 has to write this for somebody whose application stopped working on upgrade, naming the opt-in and the conversion.

Core 2371, ADO.NET 1054.

🤖 Generated with Claude Code