KDF and salt storage Regardless of the KDF I will use, let's imagine that I have to generate two keys: one for authentication and the other for encryption (which will always remain on the device that generates it until logout). Of course, the key I use to encrypt and decrypt must always be the same.
I read some answers on this site that suggested generating a random salt for both keys and saving it with these (preferably separate). But there is a problem: when the user has to decrypt the data or authenticate himself, he will need this precise salt, which must be taken from the database. Since he isn't yet authenticated, how can I trust those who ask me for this salt? Because if I gave it to anyone who asks for it, it wouldn't make sense to use it.
Maybe I am wrong about some considerations since I am a newbie. If I am not mistaken in my assumptions, how can I resolve this stalemate? I have read that some recommend using the hash of the email or username as a salt in these situations. Is it a good practice?  Consider that anyone on the client-side can see what I do on the data.
Since he isn't yet authenticated, how can I trust those who ask me for this salt? Because if I gave it to anyone who asks for it, it wouldn't make sense to use it. 


That's where you went wrong. Salts are public: their purpose is to be unique per derived key, not to be secret. The security analysis of the KDF must assume that any salt used is public, so publishing them to anyone who asks is safe. That's one of the defining properties of a salt, as opposed to a "pepper". Peppers tend to provide no benefit that can't be provided by increasing the cost parameters, and complicate storage, so they're not used much.