I am developing a public website (with https) where each user is going to register and save confidential data, this data needs to be encrypted/decrypted only by the user. I need help to know how to produce the:

  • passphrase
  • salt
  • key

The MySQL server is going to receive only the encrypted data. Me as developer, should not be able to decrypt the user's data.

For the salt what I am thinking is generate a string of random bytes when the user is registering in the website and save that salt in the user table in MySQL, so... each user is going to have his own salt. Then, in the login process, if login is successful, a PHP script returns the salt value the user has in the MySQL database and set a JavaScript Local Variable in client-side with the value of the salt, something like localStorage.setItem('SALT', "salt-value-here);

What do you think are the best/secure way to generate these values?

  • The code you provided made the question hard to understand. Programming language and library don't matter in this case. That's why I have removed it.
    – mentallurg
    Feb 9, 2023 at 4:12
  • You might want to consider using the web crypto api to implement the client-side javascript crypto. window.crypto.getRandomValues() can be used to generate a random salt, and window.crypto.subtle.deriveBits() can be used to derive a key from a password and salt by way of PBKDF2. See github.com/meixler/web-browser-based-file-encryption-decryption for a similar example.
    – mti2935
    Feb 9, 2023 at 21:30

1 Answer 1


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:

  1. user locally encrypts data blob to ciphertext
  2. user logs into website
  3. 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 ;)

  • Good answer, but SHA hashing is not good or recommended for password hashes apparently... Feb 9, 2023 at 16:07
  • Thanks for insight. @SirMuffington makes a good point I did not know. There are algorithms specifically designed for password hashing and would be a better choice (such as PBKDF2): crypto.stackexchange.com/questions/102820/…
    – Nstevens
    Feb 9, 2023 at 17:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .