salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

    ...
    PKCS5_PBKDF2_HMAC(pass, strlen(pass), "2!@$(5#@532@%#$253l5#@$", 2, ITERATION, EVP_sha512(), outputBytes, digest);
    ...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。salt をハードコーディングすると、ソースにアクセスできる人なら誰でもそれを利用できるようになり、この関数の暗号化強度が損なわれます。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

...
const salt = "some constant value";
crypto.pbkdf2(
    password,
    salt,
    iterations,
    keyLength,
    "sha256",
    function (err, derivedKey) { ... }
);

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布されると、salt を変更できないと考えられます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムの安全性が損なわれる可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     passwordLen,
                     "2!@$(5#@532@%#$253l5#@$",
                     2,
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

...
$hash = hash_pbkdf2('sha256', $password, '2!@$(5#@532@%#$253l5#@$', 100000)
...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

...
from hashlib import pbkdf2_hmac
dk = pbkdf2_hmac('sha256', password, '2!@$(5#@532@%#$253l5#@$', 100000)
...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

...
dk = OpenSSL::PKCS5.pbkdf2_hmac(password, '2!@$(5#@532@%#$253l5#@$', 100000, 256, digest)
...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、ハードコードされた salt を使用しています。

...
let ITERATION = UInt32(100000)
let salt = "2!@$(5#@532@%#$253l5#@$"
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
passwordLength,
salt,
salt.lengthOfBytesUsingEncoding(NSUTF8StringEncoding),
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
ITERATION,
derivedKey,
derivedKeyLength)
...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

    ...
    crypt(password, "2!@$(5#@532@%#$253l5#@$");
    ...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値を簡単に判別できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

    ...
    salt := "2!@$(5#@532@%#$253l5#@$"
    password := get_password()
    sha256.Sum256([]byte(salt + password)
    ...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

    ...
    crypt($password, '2!@$(5#@532@%#$253l5#@$');
    ...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードは、Hardcoded Salt を使用しています。

    ...
    from django.contrib.auth.hashers import make_password
    make_password(password, salt="2!@$(5#@532@%#$253l5#@$")
    ...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt をハードコーディングするのはよくない発想です。Hardcoded Salt を使用すると、プロジェクトの開発者全員が salt を見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、salt は簡単に変更できません。攻撃者は、salt の値を把握すると、アプリケーションの「レインボー テーブル」を計算し、ハッシュ値をより簡単に解読できます。
例 1: 次のコードはパスワードのハッシュ化にハードコーディングされた salt を使用しています。

require 'openssl'
...
password = get_password()
salt = '2!@$(5#@532@%#$253l5#@$'
hash = OpenSSL::Digest::SHA256.digest(salt + password)
...

このコードは正常に動作しますが、コードにアクセスできる全員が salt を入手できます。プログラムが頒布された後は、"2!@$(5#@532@%#$253l5#@$" という salt を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

salt 値は、暗号化の疑似ランダム数値の生成機能を使用して作成する必要があります。ランダムの salt 値を使用しないと、ハッシュまたは hmac の推測が非常に容易になり、辞書攻撃による危険が高まります。

例 1: 次のコードは salt としてパスワードを再利用します。

...
let password = getPassword();
let salt = password;
crypto.pbkdf2(
    password,
    salt,
    iterations,
    keyLength,
    "sha256",
    function (err, derivedKey) { ... }
);

salt 値は、暗号化の疑似ランダム数値の生成機能を使用して作成する必要があります。ランダムの salt 値を使用しないと、ハッシュまたは hmac の推測が非常に容易になり、辞書攻撃による危険が高まります。

例 1: 次のコードは salt としてパスワードを再利用します。

function register(){
  $password = $_GET['password'];
  $username = $_GET['username'];

  $hash = hash_pbkdf2('sha256', $password, $password, 100000);
...

salt 値は、暗号化の疑似ランダム数値の生成機能を使用して作成する必要があります。ランダムの salt 値を使用しないと、ハッシュまたは hmac の推測が非常に容易になり、辞書攻撃による危険が高まります。

例 1: 次のコードは salt としてパスワードを再利用します。

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']

  dk = hashlib.pbkdf2_hmac('sha256', password, password, 100000)
  hash = binascii.hexlify(dk)
  store(username, hash)
...

salt 値は、暗号化の疑似ランダム数値の生成機能を使用して作成する必要があります。ランダムの salt 値を使用しないと、ハッシュまたは HMAC の推測が非常に容易になり、辞書攻撃による危険が高まります。

例 1: 次のコードは salt としてパスワードを再利用します。

require 'openssl'
...
req = Rack::Response.new
password = req.params['password']
...
key = OpenSSL::PKCS5::pbkdf2_hmac(password, password, 100000, 256, 'SHA256')
...

Weak Cryptographic Hash: User-Controlled PBE Salt の問題は、次の場合に発生します。

1. 信頼できないソースを経由してデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェア セキュリティの脆弱性と同様、Weak Cryptographic Hash: User-Controlled PBE Salt は目的を達成するための手段であって、目的そのものではありません。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御の salt を使用しています。

  string salt = ConfigurationManager.AppSettings["salt"];
  ...
  Rfc2898DeriveBytes rfc = new Rfc2898DeriveBytes("password", Encoding.ASCII.GetBytes(salt));
  ...
  

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でもプロパティ salt を変更することで鍵またはパスワードの導出に使用する salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ:ユーザー制御の PBE Salt の問題は、次の場合に発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ:ユーザー制御による PBE Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー制御の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による Salt を使用しています。

    ...
    salt = getenv("SALT");
    PKCS5_PBKDF2_HMAC(pass, sizeof(pass), salt, sizeof(salt), ITERATION, EVP_sha512(), outputBytes, digest);
    ...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも、環境変数 SALT を変更することで、鍵またはパスワードの導出に使用される salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ: ユーザー制御の PBE Salt の問題は、次の場合に発生します。

1.信頼できないソースからデータがプログラムに入り込んだ場合。

2.ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ: ユーザー制御による PBE Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1.攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2.攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの「レインボー テーブル」を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による salt を使用しています。

app.get('/pbkdf2', function(req, res) {
    ...
    let salt = req.params['salt'];
    crypto.pbkdf2(
        password,
        salt,
        iterations,
        keyLength,
        "sha256",
        function (err, derivedKey) { ... }
    );
}

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でもプロパティ salt を変更することで鍵またはパスワードの導出に使用する salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

Weak Cryptographic Hash: User-Controlled PBE Salt の問題は、次の場合に発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェア セキュリティの脆弱性と同様、Weak Cryptographic Hash: User-Controlled PBE Salt は目的を達成するための手段であって、目的そのものではありません。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による salt を使用しています。

...
@property (strong, nonatomic) IBOutlet UITextField *inputTextField;
...
NSString *salt = _inputTextField.text;
const char *salt_cstr = [salt cStringUsingEncoding:NSUTF8StringEncoding];
...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     passwordLen,
                     salt_cstr,
                     salt.length,
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも UITextField inputTextField のテキストを変更することで鍵またはパスワードの導出に使用する salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ: ユーザー制御の PBE Salt の問題は、次の場合に発生します。

1.信頼できないソースを経由してデータがプログラムに入り込んだ場合。

2.ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ: ユーザー制御による PBE Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1.攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2.攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による salt を使用しています。

function register(){
  $password = $_GET['password'];
  $username = $_GET['username'];
  $salt = getenv('SALT');

  $hash = hash_pbkdf2('sha256', $password, $salt, 100000);
...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも、環境変数 SALT を変更することで、鍵またはパスワードの導出に使用される salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ:ユーザー制御の PBE Salt の問題は、次の場合に発生します。

1. 信頼できないソースを経由してデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ:ユーザー制御による PBE Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による Salt を使用しています。

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']
  salt = os.environ['SALT']

  dk = hashlib.pbkdf2_hmac('sha256', password, salt, 100000)
  hash = binascii.hexlify(dk)
  store(username, hash)
...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも、環境変数 SALT を変更することで、鍵またはパスワードの導出に使用される salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ:ユーザー制御の PBE Salt の問題は、次の場合に発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ:ユーザー制御による PBE Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による Salt を使用しています。

...
salt=io.read
key = OpenSSL::PKCS5::pbkdf2_hmac(pass, salt, iter_count, 256, 'SHA256')
...

Example 1 のコードは正常に実行されますが、この機能にアクセスできる者であれば誰でも salt のテキストを変更し、鍵やパスワードの導出に使用された salt を操作できます。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

Weak Cryptographic Hash: User-Controlled PBE Salt の問題は、次の場合に発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが、salt 内に含まれるか、またはそれ自体がパスワードベースの鍵導出関数 (PBKDF) 内の salt として使用される場合。


多くのソフトウェア セキュリティの脆弱性と同様、Weak Cryptographic Hash: User-Controlled PBE Salt は目的を達成するための手段であって、目的そのものではありません。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが PBKDF の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、自分自身のパスワードに空の salt を指定できます。ここから、各種のパスワードベースの鍵導出関数 (PBKDF) を使用してすばやく独自のパスワードを導出し、アプリケーション内で使用されている PBKDF 実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のパスワードの「クラッキング」が容易になります。
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、導出した値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による salt を使用しています。

...
@IBOutlet weak var inputTextField : UITextField!
...
let salt = (inputTextField.text as NSString).dataUsingEncoding(NSUTF8StringEncoding)
let saltPointer = UnsafePointer<UInt8>(salt.bytes)
let saltLength = size_t(salt.length)
...
let algorithm : CCPBKDFAlgorithm = CCPBKDFAlgorithm(kCCPBKDF2)
let prf : CCPseudoRandomAlgorithm = CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256)
CCKeyDerivationPBKDF(algorithm,
                     passwordPointer,
                     passwordLength,
                     saltPointer,
                     saltLength,
                     prf,
                     100000,
                     derivedKeyPointer,
                     derivedKeyLength)
...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも UITextField inputTextField のテキストを変更することで鍵またはパスワードの導出に使用する salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ:ユーザー制御の Salt の問題は、次の場合に発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが、salt 内に含まれるか、それ自体が暗号化ハッシュ関数内の salt として使用される場合。

多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ:ユーザー制御による Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが暗号化ハッシュの中で salt の全体または一部として使用されます。

ユーザー制御の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、ハッシュされているデータに空の salt を指定できます。ここから、各種のハッシュ アルゴリズムを使用して、自身の制御下でハッシュされているデータをすばやくハッシュし、アプリケーション内で使用されるハッシュ実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のデータ値の「クラッキング」が容易になります。""
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、ハッシュ済みの値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による Salt をパスワードのハッシュに使用しています。

    ...
    salt = getenv("SALT");
    password = crypt(getpass("Password:"), salt);
    ...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも、環境変数 SALT を変更することで、パスワードのハッシュに使用される salt を操作できるようになります。さらに、このコードは、パスワードの暗号ハッシュには使用してはならない crypt() 関数を使用しています。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ: ユーザー制御の Salt の問題は、次の場合に発生します。

1.信頼できないソースを経由してデータがプログラムに入り込んだ場合。

2.ユーザーが制御するデータが salt 内に追加されるか、それ自体が暗号化ハッシュ関数内の salt として使用された場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ: ユーザー制御による Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが暗号化ハッシュ関数の中で salt の全体または一部として使用されます。

ユーザー定義の salt があると、多様な攻撃が可能になります。

1.攻撃者はこの脆弱性を利用して、ハッシュされているデータに空の salt を指定できます。各種のハッシュ アルゴリズムを使用して、自身の制御下でデータをすばやくハッシュし、アプリケーションのハッシュ実装についての情報を漏洩させることができます。これにより、使用されるハッシュの特定のバリアントを制限して、他のデータ値の「クラッキング」が容易になります。
2.攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの「レインボー テーブル」を計算できるようになり、ハッシュ済みの値を簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による Salt をパスワードのハッシュに使用しています。

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  salt := r.FormValue("salt")
  password := r.FormValue("password")
  ...
  sha256.Sum256([]byte(salt + password))
}

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも環境変数 salt を変更することでパスワードのハッシュに使用する salt を操作できるようになります。さらに、このコードは、パスワードの暗号ハッシュには使用してはならない Sum256 暗号化ハッシュ関数を使用しています。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ:ユーザー制御の Salt の問題は、次の場合に発生します。

1. 信頼できないソースを経由してデータがプログラムに入り込んだ場合。

2. ユーザー制御のデータが salt 内に含まれるか、それ自体が暗号化ハッシュ関数内の salt として使用される場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ:ユーザー制御による Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが暗号化ハッシュ関数の中で salt の全体または一部として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、ハッシュされているデータに空の salt を指定できます。ここから、各種のハッシュ アルゴリズムを使用して、自身の制御下でハッシュされているデータをすばやくハッシュし、アプリケーション内で使用されるハッシュ実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のデータ値の「クラッキング」が容易になります。""
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、ハッシュ済みの値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による Salt をパスワードのハッシュに使用しています。

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']
  salt = os.environ['SALT']

  hash = hashlib.md5("%s:%s" % (salt, password,)).hexdigest()
  store(username, hash)
...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でも環境変数 SALT を変更することでパスワードのハッシュに使用する salt を操作できるようになります。さらに、このコードは、パスワードの暗号ハッシュには使用してはならない md5() 暗号化ハッシュ関数を使用しています。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ:ユーザー制御の Salt の問題は、次の場合に発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. ユーザーが制御するデータが salt 内に追加されるか、それ自体が暗号化ハッシュ関数内の salt として使用された場合。

多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ:ユーザー制御による Salt は、それ自体が目的ではなく目標を達成するための手段です。基本的には、この脆弱性は単純なものです。攻撃者はアプリケーションに悪意のあるデータを渡し、そのデータが暗号化ハッシュの salt として使用されます。

ユーザー定義の salt がある場合の問題は、多様な攻撃が可能になる点です。

1. 攻撃者はこの脆弱性を利用して、ハッシュされているデータに空の salt を指定できます。ここから、各種のハッシュ アルゴリズムを使用して、自身の制御下でハッシュされているデータをすばやくハッシュし、アプリケーション内で使用されるハッシュ実装についての情報を漏洩させることを、難なく実行できます。これにより、使用されるハッシュの特定のバリアントを制限できるため、他のデータ値の「クラッキング」が容易になります。""
2. 攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの "レインボー テーブル" を計算できるようになり、ハッシュ済みの値をより簡単に判別できるようになります。

例 1: 次のコードは、ユーザー制御による Salt をパスワードのハッシュに使用しています。

    ...
    salt = req.params['salt']
    hash = @userPassword.crypt(salt)
    ...

Example 1 のコードは正常に実行されますが、この機能を使用すれば誰でもパラメーター salt を変更することでパスワードのハッシュに使用する salt を操作できるようになります。さらに、このコードは、パスワードの暗号ハッシュには使用してはならない String#crypt() 関数を使用しています。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。

脆弱な暗号化ハッシュ: ユーザー制御の Salt の問題は、次の場合に発生します。

1.信頼できないソースを経由してデータがプログラムに入り込んだ場合。

2.ユーザーが制御するデータが salt 内に追加されるか、それ自体が暗号化ハッシュ関数内の salt として使用された場合。


多くのソフトウェアのセキュリティ脆弱性と同様に、脆弱な暗号化ハッシュ: ユーザー制御による Salt は、それ自体が目的ではなく目標を達成するための手段です。この脆弱性で、攻撃者は悪意のあるデータをアプリケーションに渡し、そのデータが暗号化ハッシュ関数の中で salt の全体または一部として使用されます。

ユーザー定義の salt があると、多様な攻撃が可能になります。

1.攻撃者はこの脆弱性を利用して、ハッシュされているデータに空の salt を指定できます。各種のハッシュ アルゴリズムを使用して、自身の制御下でデータをすばやくハッシュし、アプリケーションのハッシュ実装についての情報を漏洩させることができます。これにより、使用されるハッシュの特定のバリアントを制限して、他のデータ値の「クラッキング」が容易になります。
2.攻撃者が他のユーザーの salt を操作したり、他のユーザーを欺いて空の salt を使用させたりできると、攻撃者はアプリケーションの「レインボー テーブル」を計算できるようになり、ハッシュ済みの値を簡単に判別できるようになります。

例 1: 次のコードでは、ユーザー制御の salt を使用して暗号鍵を導出します。

let saltData = userInput.data(using: .utf8)

sharedSecret.hkdfDerivedSymmetricKey(
    using: SHA256.self,
    salt: saltData,
    sharedInfo: info,
    outputByteCount: 1000
)

例 1 のコードは正常に実行されますが、この機能を使用すれば誰でも userInput の値を変更することで暗号鍵の導出に使用する salt を操作できるようになります。悪意のあるユーザーによってパスワード ハッシュの salt が判別されたかどうかを把握するのは極めて難しいため、プログラムを頒布した後に、ユーザー制御による salt に関する問題を元に戻すのは非常に困難です。