Linux 上密码散列的第 6 个字符是什么？为什么它通常是斜杠？

Question 1

哈希格式和来源

密码哈希的格式为$<type>$<salt>$<hash>，其中<type> 5是基于 SHA-256 的哈希。盐通常至少有 8 个字符（并且在问题的示例中），因此第六个字符是盐的一部分。

这些哈希值可能是由某个版本生成的影子工具套件（源包shadow在Debian中，shadow-utils在 CentOS 中）

我试图找出代码到底为什么会偏向斜线。（感谢@thrig 最初挖掘了代码。）

总括： 这有点有趣，但没关系。

生成盐的代码

在中libmisc/salt.c，我们找到循环gensalt调用的函数：l64a

strcat (salt, l64a (random()));
do {
       strcat (salt, l64a (random()));
} while (strlen (salt) < salt_size);

该循环从中获取一个随机数random()，将其转换为字符串的一部分，并将其连接到形成盐的字符串。重复直到收集到足够的字符。

不过，发生的事情l64a更有趣。内部循环根据输入值（来自random()）一次生成一个字符：

for (i = 0; value != 0 && i < 6; i++) {
    digit = value & 0x3f;

    if (digit < 2) {
        *s = digit + '.';
    } else if (digit < 12) {
        *s = digit + '0' - 2;
    } else if (digit < 38) {
        *s = digit + 'A' - 12;
    } else {
        *s = digit + 'a' - 38;
    }

    value >>= 6;
    s++;
}

循环的第一行 ( digit = value & 0x3f) 从输入值中选取六位，子句if将这些值形成的值转换为字符。（.零、/一、0二等）

l64a接受 along但输出的值random()仅限于RAND_MAX，在 glibc 上似乎是 2147483647 或 2^31 - 1。因此，转到的值l64a是 31 位的随机数。通过一次取 6 位或 31 位值，我们得到五个合理均匀分布的字符，加上仅来自一位的第六个字符！

但是，生成的最后一个字符l64a不能是 a .，因为循环还具有条件value != 0，并且不是 a.作为第六个字符，而是l64a仅返回五个字符。因此，一半的时间，第六个字符是 a /，一半的时间l64a返回五个或更少的字符。在后一种情况下，后续字符l64a也可以在第一个位置生成斜杠，因此在全盐中，第六个字符应该有一半以上的时间是斜杠。

该代码还有一个函数可以随机化盐的长度，它是 8 到 16 个字节。斜杠字符的相同偏差也会发生在进一步的调用中，l64a这将导致第 11 个和第 12 个字符也比其他任何字符更频繁地具有斜杠。问题中提出的 100 个盐在第六位置有 46 个斜线，在第 11 和第 12 位置分别有 13 和 15 个斜线。（不到一半的盐长度短于 11 个字符）。

在 Debian 上

在 Debian 上，我无法用chpasswd问题中所示的直线重现这一点。但chpasswd -c SHA256表现出相同的行为。根据手册，默认操作（不带-c）是让 PAM 处理哈希，因此显然 Debian 上的 PAM 至少使用不同的代码来生成盐。不过，我没有查看任何发行版上的 PAM 代码。

（这个答案的前一个版本表示该效果没有出现在 Debian 上。这是不正确的。）

盐的意义和要求

但这有关系吗？正如 @RemcoGerlich 评论的那样，这几乎只是一个编码问题。它将有效地将盐的某些位修复为零，但在这种情况下这可能不会产生重大影响，因为这些位的起源是对 in 的srandom调用seedRNG：

srandom (tv.tv_sec ^ tv.tv_usec ^ getpid ());

这是用当前时间为 RNG 播种的古老习俗的变体。（tv_sec和tv_usec是当前时间的秒和微秒，getpid()如果正在运行的进程则给出进程 ID。）由于时间和 PID 不是很不可预测，因此这里的随机量可能不会大于编码可以容纳的随机量。

时间和 PID 不是您想要创建的键与，但对于盐来说可能是不可预测的。盐类必须是不同的，以防止通过一次计算对多个密码哈希进行暴力测试，但是应该也是不可预测的，以防止或减慢有针对性的预计算，这可用于缩短从获取密码散列到获取实际密码的时间。

即使有一些小问题，只要算法不会为不同的密码生成相同的盐，就应该没问题。正如问题中的列表所示，即使在循环中生成几十个，它似乎也没有。

此外，有问题的代码除了生成密码盐之外不用于任何其他用途，因此不会对其他地方的问题产生任何影响。

对于盐，另请参见，例如这个在堆栈溢出上和关于安全性。SE。

结论

结论是，你的系统没有任何问题。确保您的密码是好的，并且不在不相关的系统上使用是更值得考虑的。

Answer

哈希格式和来源

密码哈希的格式为$<type>$<salt>$<hash>，其中<type> 5是基于 SHA-256 的哈希。盐通常至少有 8 个字符（并且在问题的示例中），因此第六个字符是盐的一部分。

这些哈希值可能是由某个版本生成的影子工具套件（源包shadow在Debian中，shadow-utils在 CentOS 中）

我试图找出代码到底为什么会偏向斜线。（感谢@thrig 最初挖掘了代码。）

总括： 这有点有趣，但没关系。

生成盐的代码

在中libmisc/salt.c，我们找到循环gensalt调用的函数：l64a

strcat (salt, l64a (random()));
do {
       strcat (salt, l64a (random()));
} while (strlen (salt) < salt_size);

该循环从中获取一个随机数random()，将其转换为字符串的一部分，并将其连接到形成盐的字符串。重复直到收集到足够的字符。

不过，发生的事情l64a更有趣。内部循环根据输入值（来自random()）一次生成一个字符：

for (i = 0; value != 0 && i < 6; i++) {
    digit = value & 0x3f;

    if (digit < 2) {
        *s = digit + '.';
    } else if (digit < 12) {
        *s = digit + '0' - 2;
    } else if (digit < 38) {
        *s = digit + 'A' - 12;
    } else {
        *s = digit + 'a' - 38;
    }

    value >>= 6;
    s++;
}

循环的第一行 ( digit = value & 0x3f) 从输入值中选取六位，子句if将这些值形成的值转换为字符。（.零、/一、0二等）

l64a接受 along但输出的值random()仅限于RAND_MAX，在 glibc 上似乎是 2147483647 或 2^31 - 1。因此，转到的值l64a是 31 位的随机数。通过一次取 6 位或 31 位值，我们得到五个合理均匀分布的字符，加上仅来自一位的第六个字符！

但是，生成的最后一个字符l64a不能是 a .，因为循环还具有条件value != 0，并且不是 a.作为第六个字符，而是l64a仅返回五个字符。因此，一半的时间，第六个字符是 a /，一半的时间l64a返回五个或更少的字符。在后一种情况下，后续字符l64a也可以在第一个位置生成斜杠，因此在全盐中，第六个字符应该有一半以上的时间是斜杠。

该代码还有一个函数可以随机化盐的长度，它是 8 到 16 个字节。斜杠字符的相同偏差也会发生在进一步的调用中，l64a这将导致第 11 个和第 12 个字符也比其他任何字符更频繁地具有斜杠。问题中提出的 100 个盐在第六位置有 46 个斜线，在第 11 和第 12 位置分别有 13 和 15 个斜线。（不到一半的盐长度短于 11 个字符）。

在 Debian 上

在 Debian 上，我无法用chpasswd问题中所示的直线重现这一点。但chpasswd -c SHA256表现出相同的行为。根据手册，默认操作（不带-c）是让 PAM 处理哈希，因此显然 Debian 上的 PAM 至少使用不同的代码来生成盐。不过，我没有查看任何发行版上的 PAM 代码。

（这个答案的前一个版本表示该效果没有出现在 Debian 上。这是不正确的。）

盐的意义和要求

但这有关系吗？正如 @RemcoGerlich 评论的那样，这几乎只是一个编码问题。它将有效地将盐的某些位修复为零，但在这种情况下这可能不会产生重大影响，因为这些位的起源是对 in 的srandom调用seedRNG：

srandom (tv.tv_sec ^ tv.tv_usec ^ getpid ());

这是用当前时间为 RNG 播种的古老习俗的变体。（tv_sec和tv_usec是当前时间的秒和微秒，getpid()如果正在运行的进程则给出进程 ID。）由于时间和 PID 不是很不可预测，因此这里的随机量可能不会大于编码可以容纳的随机量。

时间和 PID 不是您想要创建的键与，但对于盐来说可能是不可预测的。盐类必须是不同的，以防止通过一次计算对多个密码哈希进行暴力测试，但是应该也是不可预测的，以防止或减慢有针对性的预计算，这可用于缩短从获取密码散列到获取实际密码的时间。

即使有一些小问题，只要算法不会为不同的密码生成相同的盐，就应该没问题。正如问题中的列表所示，即使在循环中生成几十个，它似乎也没有。

此外，有问题的代码除了生成密码盐之外不用于任何其他用途，因此不会对其他地方的问题产生任何影响。

对于盐，另请参见，例如这个在堆栈溢出上和关于安全性。SE。

结论

结论是，你的系统没有任何问题。确保您的密码是好的，并且不在不相关的系统上使用是更值得考虑的。

Question 2

根据手册，该字符是盐的一部分crypt(3)。鉴于盐的长度（ ID $5$ 和后续之间的字符串$）因显示的哈希值而异，我不确定从该特定列中为几个密码选择随机字符说明了什么。

另一方面，/ 是在以下地区更为普遍（102 个实例）全部的与其他可能的字符（大约 18 个）相比，salt 中的某些字符chpasswd似乎确实有利于 salt 中的该字符；

for x in `seq 1 100000`; do
  echo testacct:asdfasdfasdf | chpasswd -c SHA256
  awk -F: '/testacct/{print $2}' /etc/shadow | awk -F\$ '{print $3}' >> salts
done
perl -nle 'print for m/(.)/g' salts | sort | uniq -c | sort -nr | head -5

在 RedHat EL 6 系统上运行出现：

是的，中的代码表现出一种可能使字典攻击更容易的shadow-utils-4.1.5.1-5.el6偏见：/

#include <sys/time.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

// these next two borrowed from libmisc/salt.c of shadow-4.1.5.1 from
// Centos 6.8 RPM at http://vault.centos.org/6.8/os/Source/SPackages/shadow-utils-4.1.5.1-5.el6.src.rpm
char *l64a(long value)
{
    static char buf[8];
    char *s = buf;
    int digit;
    int i;

    if (value < 0) {
        abort();
    }

    for (i = 0; value != 0 && i < 6; i++) {
        digit = value & 0x3f;

        if (digit < 2) {
            *s = digit + '.';
        } else if (digit < 12) {
            *s = digit + '0' - 2;
        } else if (digit < 38) {
            *s = digit + 'A' - 12;
        } else {
            *s = digit + 'a' - 38;
        }

        value >>= 6;
        s++;
    }

    *s = '\0';

    return (buf);
}

static void seedRNG(void)
{
    struct timeval tv;
    static int seeded = 0;

    if (0 == seeded) {
        (void) gettimeofday(&tv, NULL);
        srandom(tv.tv_sec ^ tv.tv_usec ^ getpid());
        seeded = 1;
    }
}

int main(void)
{
    seedRNG();
    for (int x = 0; x < 1000; x++) {
        printf("%s\n", l64a(random()));
    }

    exit(0);
}

结果是：

% ./salttest | perl -nle 'print for m/(.)/g' | sort | uniq -c | sort -nr | head -3
 593 /
  96 8
  93 3

然后使用最新的相同例程https://github.com/shadow-maint/shadow/blob/master/libmisc/salt.c我们发现仍然存在偏见/。所以呃，是的，这是一个应该修补的错误，所以/不太受青睐，因为理想情况下，盐字符应该具有相同的权重。

Answer

根据手册，该字符是盐的一部分crypt(3)。鉴于盐的长度（ ID $5$ 和后续之间的字符串$）因显示的哈希值而异，我不确定从该特定列中为几个密码选择随机字符说明了什么。

另一方面，/ 是在以下地区更为普遍（102 个实例）全部的与其他可能的字符（大约 18 个）相比，salt 中的某些字符chpasswd似乎确实有利于 salt 中的该字符；

for x in `seq 1 100000`; do
  echo testacct:asdfasdfasdf | chpasswd -c SHA256
  awk -F: '/testacct/{print $2}' /etc/shadow | awk -F\$ '{print $3}' >> salts
done
perl -nle 'print for m/(.)/g' salts | sort | uniq -c | sort -nr | head -5

在 RedHat EL 6 系统上运行出现：

是的，中的代码表现出一种可能使字典攻击更容易的shadow-utils-4.1.5.1-5.el6偏见：/

#include <sys/time.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

// these next two borrowed from libmisc/salt.c of shadow-4.1.5.1 from
// Centos 6.8 RPM at http://vault.centos.org/6.8/os/Source/SPackages/shadow-utils-4.1.5.1-5.el6.src.rpm
char *l64a(long value)
{
    static char buf[8];
    char *s = buf;
    int digit;
    int i;

    if (value < 0) {
        abort();
    }

    for (i = 0; value != 0 && i < 6; i++) {
        digit = value & 0x3f;

        if (digit < 2) {
            *s = digit + '.';
        } else if (digit < 12) {
            *s = digit + '0' - 2;
        } else if (digit < 38) {
            *s = digit + 'A' - 12;
        } else {
            *s = digit + 'a' - 38;
        }

        value >>= 6;
        s++;
    }

    *s = '\0';

    return (buf);
}

static void seedRNG(void)
{
    struct timeval tv;
    static int seeded = 0;

    if (0 == seeded) {
        (void) gettimeofday(&tv, NULL);
        srandom(tv.tv_sec ^ tv.tv_usec ^ getpid());
        seeded = 1;
    }
}

int main(void)
{
    seedRNG();
    for (int x = 0; x < 1000; x++) {
        printf("%s\n", l64a(random()));
    }

    exit(0);
}

结果是：

% ./salttest | perl -nle 'print for m/(.)/g' | sort | uniq -c | sort -nr | head -3
 593 /
  96 8
  93 3

然后使用最新的相同例程https://github.com/shadow-maint/shadow/blob/master/libmisc/salt.c我们发现仍然存在偏见/。所以呃，是的，这是一个应该修补的错误，所以/不太受青睐，因为理想情况下，盐字符应该具有相同的权重。

Question 3

mkpasswd(1)可能是的前端crypt(3)，但它与运行不同chpasswd(1)，后者是 CentOS 上“shadow-utils”包和 Debian 上“passwd”包的一部分。相反，你应该进行同类比较。考虑以下脚本：

#!/bin/bash

# This repeatedly changes a `saltuser' password
# and grabs the salt out of /etc/shadow.
# Requires root and the existence of `saltuser' user.

if [ $EUID -ne 0 ]; then
    echo "This script requires root access to read /etc/shadow."
    exit 1
fi

grep -q saltuser /etc/passwd

if [ $? -ne 0 ]; then
    echo "This script requires the 'saltuser' to be present."
    exit 2
fi

: > /tmp/salts.txt

for i in {1..1000}; do
    PW=$(tr -cd '[[:print:]]' < /dev/urandom | head -c 64)
    echo "saltuser:${PW}" | chpasswd -c SHA256 -s 0 2> /dev/urandom
    awk -F '$' '/^saltuser/ {print $3}' /etc/shadow >> /tmp/salts.txt
done

while read LINE; do
    # 6th character in the salt
    echo ${LINE:5:1}
done < /tmp/salts.txt | sort | uniq -c | sort -rn

Debian Sid 的输出：

CentOS 7 的输出：

因此，这个问题并不是 CentOS 独有的，但很可能来自两个项目所在的上游。

Answer

mkpasswd(1)可能是的前端crypt(3)，但它与运行不同chpasswd(1)，后者是 CentOS 上“shadow-utils”包和 Debian 上“passwd”包的一部分。相反，你应该进行同类比较。考虑以下脚本：

#!/bin/bash

# This repeatedly changes a `saltuser' password
# and grabs the salt out of /etc/shadow.
# Requires root and the existence of `saltuser' user.

if [ $EUID -ne 0 ]; then
    echo "This script requires root access to read /etc/shadow."
    exit 1
fi

grep -q saltuser /etc/passwd

if [ $? -ne 0 ]; then
    echo "This script requires the 'saltuser' to be present."
    exit 2
fi

: > /tmp/salts.txt

for i in {1..1000}; do
    PW=$(tr -cd '[[:print:]]' < /dev/urandom | head -c 64)
    echo "saltuser:${PW}" | chpasswd -c SHA256 -s 0 2> /dev/urandom
    awk -F '$' '/^saltuser/ {print $3}' /etc/shadow >> /tmp/salts.txt
done

while read LINE; do
    # 6th character in the salt
    echo ${LINE:5:1}
done < /tmp/salts.txt | sort | uniq -c | sort -rn

Debian Sid 的输出：

CentOS 7 的输出：

因此，这个问题并不是 CentOS 独有的，但很可能来自两个项目所在的上游。

Linux 上密码散列的第 6 个字符是什么？为什么它通常是斜杠？

答案1

哈希格式和来源

生成盐的代码

在 Debian 上

盐的意义和要求

结论

答案2

答案3

相关内容