One password can produce different records
Identical passwords and all other parameters yield the same deterministic result. Different record salts allow distinct verifier values under the same scheme, reducing direct reuse of one precomputation across accounts.
Verification must reuse the record’s actual salt. Replacing a lost one with a fresh value normally cannot verify the old record, so storage commonly keeps salt, result, algorithm and cost information together.
References: [1]
Public storage does not remove generation rules
Salt is generally stored with the verifier rather than hidden permanently. NIST calls for minimizing collisions among records; one fixed constant for every account loses the intended record separation regardless of a field being named salt.
A separate verifier secret, often called a pepper, needs independent protection. If it leaks together with all records, the system cannot retain a guarantee requiring attackers to lack that secret. Salt and such a secret rely on different assumptions.
References: [1]
Derivation uses have their own salt contract
HKDF also uses salt to support extraction and independence, but RFC 5869 defines operation without an available salt and permits some reuse. Password-record separation rules are therefore not identical to every interface using the name salt.
Salting alone neither supplies adequate guessing cost in every construction nor creates secret entropy. Password hashing still needs cost parameters, while derivation depends on material and purpose; the construction matters more than the presence of a salt field.