我误解了哈希盐是什么？ [英] Am I misunderstanding what a hash salt is?

问题描述

我正在为我们的代码库添加哈希摘要生成功能。我希望使用一个字符串作为散列盐，以便可以将预先知道的密钥/密码短语预置为需要散列的任何内容。我是否误解了这个概念？

解决方案

salt是一个随机元素，添加到加密函数的输入中，目标是在每次调用时以不同的方式影响处理和输出。与密钥相对的salt并不意味着保密。一个世纪前，用于加密或认证的加密方法是秘密的。然后，随着计算机的出现，人们意识到保持一种完全秘密的方法是困难的，因为这意味着保持软件本身的机密性。一些定期写入磁盘的东西，或者作为一些专用硬件而化身，难以保密。因此，研究人员将方法分为两个不同的概念：算法（它是公开的并成为软件和硬件）和键（该算法的一个参数，存在在处理过程中仅在易失性RAM中）。密钥集中了秘密并且是纯数据。当密钥存储在人类的大脑中时，它通常被称为密码，因为人类比单词更善于记忆单词。然后密钥本身后来分裂了。事实证明，为了正确的加密安全性，我们需要两件事：一个机密参数和一个可变参数。基本上，重复使用相同的密钥用于不同的用途往往会造成麻烦;它经常泄露信息。在某些情况下（特别是流密码，但也用于哈希密码），它泄漏太多并导致成功的攻击。所以经常需要可变性，每次密码方法运行时都会发生变化。现在最好的部分是大多数时候，变化和秘密不需要合并。也就是说，我们可以将机密与变量分开。因此，密钥分为：

• 秘密密钥，通常称为密钥;
  
• 通常随机选择的变量元素，根据算法类型将其称为salt或IV（作为初始值）。
  

只有密钥需要保密。可变元素需要所有相关方都知道，但它可以是公开的。这是一件幸事，因为分享密钥是困难的;用于分发这种秘密的系统会发现，每次运行该算法时都会变化的变量部分会很昂贵。

在存储散列密码的上下文中，上面的解释变为以下内容：

• 重新使用密钥意味着两个用户碰巧选择相同的密码。如果密码只是散列，那么两个用户将获得相同的散列值，并显示。这里是泄漏。
  
• 类似地，没有散列，攻击者可以使用预先计算的表进行快速查找;他也可以同时攻击数千个密码。这仍然使用相同的泄漏，只是以一种方式来证明为什么泄漏是不好的。


• 腌制意味着将一些变量数据添加到散列函数输入中。那个可变数据就是盐。盐的要点是两个不同的用户应该尽可能使用不同的盐。但密码验证者需要能够重新计算密码中的同一个散列，因此他们必须有权访问salt。
  

由于盐必须可供验证者访问，但不一定是保密的，通常将盐值与散列值一起存储。例如，在Linux系统上，我可以使用以下命令：

  openssl passwd -1 -saltzapblah 
  

计算散列函数密码，散列函数MD5适用于 / etc / password 或 / etc / shadow 文件，密码为blah和盐zap（这里我明确选择盐，但在实际情况下应该随机选择）。输出结果如下：

  $ 1 $ zap $ t3KZajBWMA7dVxwut6y921 
  

其中美元符号用作分隔符。最初的1标识散列方法（MD5）。盐在那里，用明文表示。最后一部分是散列函数输出。

有一个关于如何将salt和密码作为hash函数的输入的规范（某处）（至少在glibc源代码，可能在其他地方）。

编辑：在登录和密码用户认证系统中，登录充当一个可接受的盐（两个不同的用户将具有不同的登录名），但是这并不能捕获给定用户改变他的密码的情况（新密码是否与旧密码相同将会泄漏）。

I am working on adding hash digest generating functionality to our code base. I wanted to use a String as a hash salt so that a pre-known key/passphrase could be prepended to whatever it was that needed to be hashed. Am I misunderstanding this concept?

解决方案

A salt is a random element which is added to the input of a cryptographic function, with the goal of impacting the processing and output in a distinct way upon each invocation. The salt, as opposed to a "key", is not meant to be confidential.

One century ago, cryptographic methods for encryption or authentication were "secret". Then, with the advent of computers, people realized that keeping a method completely secret was difficult, because this meant keeping software itself confidential. Something which is regularly written to a disk, or incarnated as some dedicated hardware, has trouble being kept confidential. So the researchers split the "method" into two distinct concepts: the algorithm (which is public and becomes software and hardware) and the key (a parameter to the algorithm, present in volatile RAM only during processing). The key concentrates the secret and is pure data. When the key is stored in the brain of a human being, it is often called a "password" because humans are better at memorizing words than bits.

Then the key itself was split later on. It turned out that, for proper cryptographic security, we needed two things: a confidential parameter, and a variable parameter. Basically, reusing the same key for distinct usages tends to create trouble; it often leaks information. In some cases (especially stream ciphers, but also for hashing passwords), it leaks too much and leads to successful attacks. So there is often a need for variability, something which changes every time the cryptographic method runs. Now the good part is that most of the time, variability and secret need not be merged. That is, we can separate the confidential from the variable. So the key was split into:

• the secret key, often called "the key";
• a variable element, usually chosen at random, and called "salt" or "IV" (as "Initial Value") depending on the algorithm type.

Only the key needs to be secret. The variable element needs to be known by all involved parties but it can be public. This is a blessing because sharing a secret key is difficult; systems used to distribute such a secret would find it expensive to accommodate a variable part which changes every time the algorithm runs.

In the context of storing hashed passwords, the explanation above becomes the following:

• "Reusing the key" means that two users happen to choose the same password. If passwords are simply hashed, then both users will get the same hash value, and this will show. Here is the leakage.
• Similarly, without a hash, an attacker could use precomputed tables for fast lookup; he could also attack thousands of passwords in parallel. This still uses the same leak, only in a way which demonstrates why this leak is bad.
• Salting means adding some variable data to the hash function input. That variable data is the salt. The point of the salt is that two distinct users should use, as much as possible, distinct salts. But password verifiers need to be able to recompute the same hash from the password, hence they must have access to the salt.

Since the salt must be accessible to verifiers but needs not be secret, it is customary to store the salt value along with the hash value. For instance, on a Linux system, I may use this command:

openssl passwd -1 -salt "zap" "blah"

This computes a hashed password, with the hash function MD5, suitable for usage in the /etc/password or /etc/shadow file, for the password "blah" and the salt "zap" (here, I choose the salt explicitly, but under practical conditions it should be selected randomly). The output is then:

$1$zap$t3KZajBWMA7dVxwut6y921

in which the dollar signs serve as separators. The initial "1" identifies the hashing method (MD5). The salt is in there, in cleartext notation. The last part is the hash function output.

There is a specification (somewhere) on how the salt and password are sent as input to the hash function (at least in the glibc source code, possibly elsewhere).

Edit: in a "login-and-password" user authentication system, the "login" could act as a passable salt (two distinct users will have distinct logins) but this does not capture the situation of a given user changing his password (whether the new password is identical to an older password will leak).

这篇关于我误解了哈希盐是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！