How to store salt in a distributed environment

Question

I do not know how to use the concept of salt in my scenario.

Suppose I have a client desktop application that encrypts data for specific users and sends it to a remote server. The client application generates a key with PKCS # 5, with a user password and SALT. Remote Desktop should NEVER be in contact with a user password.

Suppose we generate a random salt for encryption. The client application can encrypt data and send it to a remote server. If a user tries to access his data on another computer, how can he decrypt it, since the salt is unknown?

I think that using the same salt all the time (hardcoded in the application) is not a good idea (obfuscation protection is bad).

How can I solve my problem?

Answer 1

Salt is stored in unencrypted form along with encrypted data.

The purpose of the salt is to prevent an attacker from pre-computing a dictionary of encrypted passwords. (As in the case, the attacker spends a year or whatever generates the encrypted form of each word in each language.)

Another purpose of the salt is to make sure that two users have different encrypted passwords, even if their unencrypted passwords are the same.

None of the goals require salt to be kept secret.

[update, clarify]

See Wikipedia for Salt (cryptography) . In particular, read the opening paragraphs.

The purpose of the salt is to accept a non-random input (for example, user-provided data) and make it random before passing it through a cryptographic function. For this to work, salt must be randomly generated for each input.

A traditional example is storing encrypted passwords. Most users reliably choose non-random passwords, therefore without salt everyone who selects "SEKRIT" as a password ends the work with the same encrypted password in the password database. The solution is to add a random salt before encrypting the password, and then save it (in clear text) along with the encrypted password.

Answer 2

If you enable a salt with encrypted data, the client application on another computer can successfully calculate the hash password.

Answer 3

There is one aspect of salting in a distributed environment that is not covered by any of the answers that I have seen so far. If there are several databases on one site that need to be synchronized, how to protect yourself from a race condition in which random salt is generated on two or more sites at the same time. When the databases are consistent, how do you know which salt column for a given row is correct?

IMHO, the case for the idea that the salt value should be constantly recalculated by a random string was not made against using something like a primary key (PC) for a user string. Before answering, break away, listen to me.

• Any reasonable hash function will create a completely different hash no matter how much the plain text changes (one or 100 characters added).
• If you use PK, the value is independent of the information provided by the user.
• Like any salting action, PK-as-salt can be inserted anywhere in plain text using an algorithm. It should not be at the beginning or at the end.
• In a distributed environment, there is no race condition in the salt column because there is no salt column.
• Using an implied salt such as PK still makes each hash different, even if two people use the same password. Thus, the idea of ​​PK-as-salt does what salt should do without the complications of reconciliation.