如何在分布式环境中存储盐
我不知道如何在我的场景中使用“盐概念”。
假设我有一个客户端桌面应用程序，它为特定用户加密数据并将其发送到远程服务器。客户端应用程序使用 PKCS#5 生成密钥，其中包含用户密码和 SALT。远程桌面绝不能接触用户的密码。
假设我们为加密生成随机盐。客户端应用程序可以加密数据，并将其发送到远程服务器。如果用户尝试在另一台计算机上访问他的数据，由于盐未知，它将如何解密？
我认为始终使用相同的盐（在应用程序中硬编码）不是一个好主意（混淆的安全性很差）。
我该如何解决我的问题？
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 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
到目前为止，我所看到的任何答案都没有涵盖分布式环境中加盐的一个方面。如果一个站点有多个需要保持同步的数据库，那么如何防止两个或多个站点几乎同时生成随机盐的竞争条件。当数据库协调一致时，如何知道给定行的哪个盐列是正确的？
恕我直言，盐值需要是不断重新计算的随机字符串的想法并没有反对使用用户行的主键（PK）之类的东西。在你惊讶地回答之前，先听我说完。
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.
如果将盐包含在加密数据中，则另一台计算机上的客户端应用程序可以成功计算密码哈希。
If you include the salt with the encrypted data, then the client application on another computer can successfully compute the password hash.
盐与加密数据一起以未加密的方式存储。
盐的目的是防止攻击者预先计算加密密码的字典。 （例如，攻击者花费一年或其他时间生成每种语言中每个单词的加密形式。）
盐的另一个目的是确保两个用户将拥有不同的加密密码，即使他们的未加密密码相同。
这两个目的都不需要盐保密。
[更新，详细说明]
请参阅Salt（密码学）的维基百科条目。特别是阅读介绍性段落。
盐的目的是获取非随机输入（例如，用户提供的数据）并在将其传递给加密函数之前使其随机。为此，必须为每个输入随机生成盐。
传统的例子是存储加密的密码。大多数用户可靠地选择非随机密码，因此如果没有盐，每个选择“SEKRIT”作为密码的人最终都会在密码数据库中获得相同的加密密码。解决方案是在加密密码之前添加随机盐，然后将其（以明文形式）与加密密码一起存储。
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.