Why is it recommended to hash passwords with a secret salt? NIST recommends doing an additional round of hashing using a secret salt:


  In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.


Questions about this:


Is it safe to ignore this advice? Are there any known vulnerabilities if we don't do this additional iteration?
How should we implement this additional iteration, if the secret salt must be stored separately but need to be available when hashing a password? Should we use a dedicated server for the secret salt, transferred to the verification server using a secure protocol? The secret salt may stay in the verification server's memory, does this matter?
NIST document section 5.1.1.2 Memorized Secret Verifiers.

That section is a "SHOULD" not a "SHALL".

It is standard practice not to keep the salt secret but to save it with the password hashed verifier.

If the salt is not secret a brute force search is possible if the password is weak such as being on a list of frequent passwords. One example source of such frequent passwords is SecLists.

If the salt is secret such a brute force search will not succeed. Note: stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module) and such a device is generally not available.