Just so we're on the same page, a salt is really only useful for two things. 1) producing unique hashes of the same plaintext and 2) rendering a typical hash attack extremely time consuming. #2 is becoming less advantageous with the evolving computational landscape however.
For the best way to secure these values, what is available leaves considerable control gaps. Depending on what your org considers an acceptable level of risk, these may be fine. There are many (this is only one thread) discussions as to whether the salt should be protected or not, how to manage salts, whether they should be assumed known, etc. In one case, the salt is encrypted, but the secret key to decrypt the salt must be stored somewhere. Without it, you cannot verify the validity of the stored password hash. The best way is to create a hash of SALT+PASSWORD using one of the current secure algorithms, and store that hash result in the database. Storage of the salt would be done in some hard-to-get-to location such as a Hardware Security Module. Keep in mind that a (live) compromised web server will give up whatever data is accessible by the web server process. Decrypted files or file systems, HSM data, Databases, etc. Data in HSM, or on an encrypted filesystem only help when the machine is powered off, lost, stolen, etc.
If the website will truly never have access to the secret key, and the only data being saved is the ciphertext (using a current and suitable cipher), there is little need to go much further with the server. This assumes the user's workflow would be:
- user locally encrypts data blob to ciphertext
- user logs into website
- user uploads ciphertext
Decisions must be made how to manage the secrets. Symmetric encryption (file locked with password/phrase) requires that secret to be known by the recipient in order to decrypt the data. That secret becomes compromised as soon as it is relayed from the sender to the recipient and it usually gets written down somewhere. Asymmetric encryption (ssh keys for instance) requires a fair bit more work by the end user, become difficult to manage, but comes without relaying the secret key.
You could additionally transfer the uploaded ciphertext from the public website where it was uploaded, to more protected (NOT publicly available) storage to reduce window of risk (eg: Linux incron utility) to data during a compromise and also absolutely require MFA for any account access (and not the SMS kind ;)
