Hello,
Long story short, this is not an issue given the way CryptPad works.
More precisely, in order to log-in, the client never sends their credentials directly, but the output of a key derivation function (KDF) based on their login, password and, if defined, the instance loginSalt.
This implies that in any case, the loginSalt is exposed to the client (otherwise they cannot log in), thus making this information public about the instance: it’s not a security issue to have it available.
Usually, salting is used in case of database leaks, where pre-established associative tables cannot be used to obtain passphrases from their digest. Here the same can be applied as, if one is using the same login-passphrase on multiple instances, and the data storage of these instances get compromised, it won’t be easy to verify that the user is present on both instances (even intractable only from the login as it’s not known from the server). Finally, the use of a KDF renders the cost of brute-forcing unattractive to malicious adversaries.
For a more technical and formal answer, you can refer to the CryptPad White paper, “Section 6.1: Registration and login” and “Section 2: Threat model”. And the explanations about the purpose of salting in CryptPad is detailed in the documentation.
