问题
I dont know how to use the "salt concept" in my scenario.
Suppose I have a client desktop application that encrypts data for specific users and send it to a remote server. The client application generate a key with PKCS#5, with the user's password and a SALT. The remote desktop must NEVER be in contact with the user's password.
Suppose we generate a random salt for an encryption. The client application can encrypt the data, and sent it to the remote server. If the user try to access his data on another computer, how will it be able to 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 (security by obfuscation is bad).
How can I solve my problem ?
回答1:
The salt is stored unencrypted along with the encrypted data.
The purpose of a salt is to prevent an attacker from precomputing a dictionary of encrypted passwords. (As in, the attacker spends a year or whatever generating the encrypted form of every word in every language.)
The other purpose of a salt is to make sure that two users will have different encrypted passwords even if their unencrypted passwords are the same.
Neither purpose requires that the salt remain secret.
[update, to elaborate]
See the Wikipedia entry for Salt (cryptography). In particular, read the introductory paragraphs.
The purpose of a salt is to take a non-random input (e.g., user-provided data) and make it random before passing it through a cryptographic function. For this to work, the salt must be randomly generated for each input.
The traditional example is storing encrypted passwords. Most users reliably choose non-random passwords, so without a salt, everyone who chooses "SEKRIT" as a password will wind up with the same encrypted password in the password DB. The solution is to add a random salt before encrypting the password, and then to store it (in plaintext) along with the encrypted password.
回答2:
If you include the salt with the encrypted data, then the client application on another computer can successfully compute the password hash.
回答3:
There is an aspect of salting in a distributed environment which is not being covered by any of the answers I have seen thus far. If one's site has multiple databases which need to be kept in sync, how does one guard against a race condition in which a random salt generated on two or more sites near-simultaneously. When the databases are reconciled, how's one to know which salt column for a given row is the correct one?
IMHO, the case for the idea that a salt value needs to be a constantly recalculated random string has not been made against using something like the primary key (PK) for the user row. Before you reply aghast, hear me out.
- Any reasonable hash function will produce a completely different hash no matter how much the plain text is changes (one or 100 characters added).
- If you use the PK then the value is independent of all user-provided information.
- Just like any salting action, the PK-as-salt can be inserted anywhere in the plain text by the algorithm. It does not need to be at the start or end.
- In a distributed environment, there is no race condition about the salt column because there is no salt column.
- Using an implied salt like the PK still makes each hash look different even if two folks use the same password. Thus the PK-as-salt idea does what a salt should do without the complications of reconciliations.
来源：https://stackoverflow.com/questions/6141537/how-store-salt-in-distributed-environment