Linuxでは、パスワードハッシュの6番目の文字は何ですか？なぜ通常スラッシュですか？

Question

ハッシュ形式とソース

パスワードハッシュの形式はSHA-256ベースのハッシュです$<type>$<salt>$<hash>。<type> 5Saltは通常長さが8文字以上であるため（質問の例では）、6番目の文字はSaltの一部です。

このハッシュは、おそらく次のバージョンによって生成されたでしょう。シャドウツールキット(ソースパッケージshadowDebian ではshadow-utilsCentOSで）

コードがスラッシュに向かって偏った理由が正確に何であるかを調べようとしています。（元のコードを掘り下げた@thrigに感謝します。）

要約： ちょっと面白いですが大丈夫です。

塩を生成するコード

ループで呼び出される関数をlibmisc/salt.c見つけます。gensaltl64a

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

ループはそれから任意の数を取り、random()文字列の一部に変換し、ソルトを形成する文字列に接続します。十分な文字が収集されるまで繰り返します。

しかし、起こったことはl64aはるかに興味深かったです。内部ループは（から）入力値に基づいてrandom()一度に1文字を生成します。

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）の最初の行は入力値から6ビットを選択し、句はifこれらの値で構成される値を文字に変換します。 ( .0、1、2/など0)

l64aa を許可しますlongが、出力値は glibc で 2147483647 または 2^31 - 1 に見えるようにrandom()制限されます。RAND_MAXしたがって、送信される値l64aは31ビット乱数です。一度に6ビットまたは31ビットの値を使用すると、合理的に均等な間隔の5文字とわずか1ビットから6番目の文字を取得できます。

ただし、生成された最後の文字はループにも条件があるため、l64aaにすることはできません。aは6番目の文字ではなく、5文字だけを返します。したがって、半分の場合、6番目の文字はで、残りの半分は5文字以下を返します。後者の場合、後続の文字も最初の位置にスラッシュを生成できるため、ソルト全体の6番目の文字は半分以上のスラッシュでなければなりません。.value != 0.l64a/l64al64a

コードには、ソルトの長さ（8〜16バイト）をランダムに指定する機能もあります。スラッシュ文字の同じバイアスは追加の呼び出しでも発生するため、l64a11番目と12番目の文字でも他の文字よりもスラッシュが頻繁に使用されます。問題に示された100個のソルトには、6番目の位置に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そして実行中のプロセスの場合、プロセスIDを提供するtv_usec現在の時間の秒とマイクロ秒ですgetpid()。）時間とPIDは予測不可能ではありません。

時間とPIDはあなたが作りたいものではありません鍵しかし、塩では予測できません。塩類〜しなければならない単一の計算で複数のパスワードハッシュの無差別代入テストを防ぐことは異なりますが、しなければならないまた、予測不可能なターゲット事前計算を防止したり、速度を遅くしたりすることで、パスワードハッシュを取得するのに実際のパスワードを取得するのにかかる時間を短縮することができます。

マイナーな問題があっても、アルゴリズムが異なるパスワードに対して同じソルトを生成しない限り、問題ありません。質問のリストからわかるように、ループから数十を生成しても機能しないようです。

また、問題のコードはパスワードソルト生成以外の目的には使用されないため、他の場所では問題には影響しません。

塩については、以下を参照してください。これはスタックオーバーフローにありますそしてセキュリティについて。 SE。

結論として

結論は、システムに問題がないということです。パスワードが良好で無関係なシステムで使用されていないことを確認することは、考慮する価値がある以上のものです。

Answer 1

ハッシュ形式とソース

パスワードハッシュの形式はSHA-256ベースのハッシュです$<type>$<salt>$<hash>。<type> 5Saltは通常長さが8文字以上であるため（質問の例では）、6番目の文字はSaltの一部です。

このハッシュは、おそらく次のバージョンによって生成されたでしょう。シャドウツールキット(ソースパッケージshadowDebian ではshadow-utilsCentOSで）

コードがスラッシュに向かって偏った理由が正確に何であるかを調べようとしています。（元のコードを掘り下げた@thrigに感謝します。）

要約： ちょっと面白いですが大丈夫です。

塩を生成するコード

ループで呼び出される関数をlibmisc/salt.c見つけます。gensaltl64a

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

ループはそれから任意の数を取り、random()文字列の一部に変換し、ソルトを形成する文字列に接続します。十分な文字が収集されるまで繰り返します。

しかし、起こったことはl64aはるかに興味深かったです。内部ループは（から）入力値に基づいてrandom()一度に1文字を生成します。

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）の最初の行は入力値から6ビットを選択し、句はifこれらの値で構成される値を文字に変換します。 ( .0、1、2/など0)

l64aa を許可しますlongが、出力値は glibc で 2147483647 または 2^31 - 1 に見えるようにrandom()制限されます。RAND_MAXしたがって、送信される値l64aは31ビット乱数です。一度に6ビットまたは31ビットの値を使用すると、合理的に均等な間隔の5文字とわずか1ビットから6番目の文字を取得できます。

ただし、生成された最後の文字はループにも条件があるため、l64aaにすることはできません。aは6番目の文字ではなく、5文字だけを返します。したがって、半分の場合、6番目の文字はで、残りの半分は5文字以下を返します。後者の場合、後続の文字も最初の位置にスラッシュを生成できるため、ソルト全体の6番目の文字は半分以上のスラッシュでなければなりません。.value != 0.l64a/l64al64a

コードには、ソルトの長さ（8〜16バイト）をランダムに指定する機能もあります。スラッシュ文字の同じバイアスは追加の呼び出しでも発生するため、l64a11番目と12番目の文字でも他の文字よりもスラッシュが頻繁に使用されます。問題に示された100個のソルトには、6番目の位置に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そして実行中のプロセスの場合、プロセスIDを提供するtv_usec現在の時間の秒とマイクロ秒ですgetpid()。）時間とPIDは予測不可能ではありません。

時間とPIDはあなたが作りたいものではありません鍵しかし、塩では予測できません。塩類〜しなければならない単一の計算で複数のパスワードハッシュの無差別代入テストを防ぐことは異なりますが、しなければならないまた、予測不可能なターゲット事前計算を防止したり、速度を遅くしたりすることで、パスワードハッシュを取得するのに実際のパスワードを取得するのにかかる時間を短縮することができます。

マイナーな問題があっても、アルゴリズムが異なるパスワードに対して同じソルトを生成しない限り、問題ありません。質問のリストからわかるように、ループから数十を生成しても機能しないようです。

また、問題のコードはパスワードソルト生成以外の目的には使用されないため、他の場所では問題には影響しません。

塩については、以下を参照してください。これはスタックオーバーフローにありますそしてセキュリティについて。 SE。

結論として

結論は、システムに問題がないということです。パスワードが良好で無関係なシステムで使用されていないことを確認することは、考慮する価値がある以上のものです。

Linuxでは、パスワードハッシュの6番目の文字は何ですか？なぜ通常スラッシュですか？

ベストアンサー1

ハッシュ形式とソース

塩を生成するコード

Debian で

塩の意味と要件

結論として

おすすめ記事