空の HMAC 鍵を使用するのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。
例 1: 次のコードでは、空の鍵で HMAC を計算しています。

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
             Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
  EXPORTING
    if_algorithm = 'SHA3'
    if_key       = space
  RECEIVING
    ro_object    = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...

Example 1 に示すコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1 のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。

空の HMAC 鍵を使用するのはよくない発想です。 HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。 空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。
例 1: 次のコードでは、空の鍵で HMAC を計算しています。

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
  string hmacKey = "";
  byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
  hmac.Key = keyBytes;
  ...
}
...

Example 1 のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1 のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。

空の HMAC 鍵を決して使用しないでください。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。

例 1: 次のコードでは、空の鍵で HMAC を計算しています。

import "crypto/hmac"
...
hmac.New(md5.New, []byte(""))
...

Example 1 のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1 のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。

空の HMAC 鍵を使用するのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。
例 1: 次のコードでは、空の HMAC 鍵で HMAC ハッシュを生成しています。

...
let hmacKey = "";
let hmac = crypto.createHmac("SHA256", hmacKey);
hmac.update(data);
...

例 1 のコードは正常に実行される可能性がありますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くかもしれません。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

空の HMAC 鍵を使用するのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。

例 1: 次のコードでは、空の鍵で HMAC を計算しています。

...
CCHmac(kCCHmacAlgSHA256, "", 0, plaintext, plaintextLen, &output);
...

Example 1 のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1 のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。

空の HMAC 鍵を使用するのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。

例 1: 次のコードでは、空の鍵で HMAC を計算しています。

import hmac
...
mac = hmac.new("", plaintext).hexdigest()
...

Example 1 のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1 のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。

空の HMAC 鍵を使用するのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。

例 1: 次のコードでは、空の鍵で HMAC を計算しています。

...
digest = OpenSSL::HMAC.digest('sha256', '', data)
...

Example 1 のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1 のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。

空の HMAC 鍵を使用するのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵のサイズに依存します。空の鍵を使用すると、HMAC 関数の暗号化強度が損なわれます。

例 1: 次のコードでは、空の鍵で HMAC を計算しています。

...
CCHmac(UInt32(kCCHmacAlgSHA256), "", 0, plaintext, plaintextLen, &output)
...

Example 1 のコードは正常に実行されますが、そのコードにアクセスしたユーザーは空の HMAC 鍵が使われていることに気付くことができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空の HMAC キーを変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。また Example 1 のコードは、フォージェリ攻撃や鍵回復攻撃に対して脆弱です。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、空の文字列をパスワード引数として PBKDF に渡します。

...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...

コードにアクセスできれば、空のパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、空のパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空のパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、空のパスワードが使われている証拠を割り出すことが可能です。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、空の文字列をパスワード引数として PBKDF に渡します。

const pbkdfPassword = "";
crypto.pbkdf2(
    pbkdfPassword,
    salt,
    numIterations,
    keyLen,
    hashAlg,
    function (err, derivedKey) { ... }
)

コードにアクセスできれば誰でも、空のパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、空のパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空のパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、空のパスワードが使われている証拠を割り出すことが可能です。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、空の文字列をパスワード引数として PBKDF に渡します。

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     "",
                     0,
                     salt,
                     saltLen
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

コードにアクセスできれば、空のパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、空のパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空のパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、空のパスワードが使われている証拠を割り出すことが可能です。

例 2: 比較的低いレベルの API では、関数がメモリ中の引数の場所から始まる連続するバイト数として引数の値を読み込むことができるように、引数の値自体とともに引数の長さを渡すことが必要な場合があります。次のコードは、PBKDF に、ゼロをパスワード長の引数として渡します。

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     0,
                     salt,
                     saltLen
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

このシナリオでは、password に強力で適切に管理されたパスワードの値が含まれる場合でも、パスワードの長さをゼロで渡すと、空パスワード、null パスワード、または予期せぬ脆弱なパスワード値になります。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、空の文字列をパスワード引数として PBKDF に渡します。

...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...

コードにアクセスできれば、空のパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることが誰にでも判別できます。さらに、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性があります。攻撃者が、空のパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空のパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、空のパスワードが使われている証拠を割り出すことが可能です。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、空の文字列をパスワード引数として PBKDF に渡します。

from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...

コードにアクセスできれば、空のパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、空のパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空のパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、空のパスワードが使われている証拠を割り出すことが可能です。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、空の文字列をパスワード引数として PBKDF に渡します。

...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...

コードにアクセスできれば、空のパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、空のパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空のパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、空のパスワードが使われている証拠を割り出すことが可能です。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、空の文字列をパスワード引数として PBKDF に渡します。

...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...

コードにアクセスできれば、空のパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、空のパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、空のパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、空のパスワードが使われている証拠を割り出すことが可能です。

例 2: 比較的低いレベルの API では、関数がメモリ中の引数の場所から始まる連続するバイト数として引数の値を読み込むことができるように、引数の値自体とともに引数の長さを渡すことが必要な場合があります。次のコードは、PBKDF に、ゼロをパスワード長の引数として渡します。

...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...

このシナリオでは、password に強力で適切に管理されたパスワードの値が含まれる場合でも、パスワードの長さをゼロで渡すと、空パスワード、null パスワード、または予期せぬ脆弱なパスワード値になります。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

...
encryptionKey = "lakdsljkalkjlksdfkl".
...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

    ...
    var encryptionKey:String = "lakdsljkalkjlksdfkl";
    var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
    ...
    var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
    ...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号化キーはハードコーディングしないでください。これにより、暗号化キーがプロジェクトの開発者全員に見えてしまい、問題の修正が極めて困難になるためです。コードの運用後に暗号鍵を変更するには、ソフトウェア パッチが必要です。暗号鍵が保護するアカウントが危険にさらされると、組織はセキュリティとシステム可用性のいずれかを選択することを迫られます。

例 1: 次のコードは、ハードコード暗号化鍵を使用して AES 暗号を実行します。

...
Blob encKey = Blob.valueOf('YELLOW_SUBMARINE');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...

このコードにアクセスできる全員が、暗号鍵を閲覧できます。アプリケーションが頒布された後は、ソフトウェア パッチを適用する以外に暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。アプリケーションの実行可能ファイルにアクセスできる攻撃者は、暗号鍵の値を抽出できます。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: The following code uses a hardcoded encryption key:

...
using (SymmetricAlgorithm algorithm = SymmetricAlgorithm.Create("AES"))
{
  string encryptionKey = "lakdsljkalkjlksdfkl";
  byte[] keyBytes = Encoding.ASCII.GetBytes(encryptionKey);
  algorithm.Key = keyBytes;
  ...
}

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号鍵をハードコーディングするのはよくない発想です。暗号鍵をハードコーディングするとプロジェクトの開発者全員が暗号鍵を見ることができるだけでなく、問題の修復も非常に困難です。コードが実運用に入ると、ソフトウェアにパッチを当てない暗号鍵を変更できません。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

...
char encryptionKey[] = "lakdsljkalkjlksdfkl";
...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者がアプリケーションの実行可能ファイルにアクセスできる場合、使用される暗号鍵の値が含まれているコードを逆アセンブルすることができます。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

	...
	<cfset encryptionKey = "lakdsljkalkjlksdfkl" />
	<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
	...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号鍵をハードコーディングすることは推奨されません。プロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。そのコードが実運用に入ったら、暗号鍵の変更にはソフトウェア パッチを必要とします。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択することになります。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

...
key := []byte("lakdsljkalkjlksd");
block, err := aes.NewCipher(key)
...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

...
var crypto = require('crypto');
var encryptionKey = "lakdsljkalkjlksdfkl";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

パスワードは絶対にハードコーディングしないでください。開発者全員にパスワードが開示されるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、おそらくパスワードを変更する唯一の方法は、プログラムのパッチです。パスワードで保護するアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。
例 1: 次の JSON は、ハードコーディングされたパスワードを使用しています。

...
{
  "username":"scott"
  "password":"tiger"
}
...

この構成は有効である可能性がありますが、構成にアクセスできる人は誰でもパスワードにもアクセスできてしまいます。プログラムがリリースされた後、デフォルトのユーザー アカウント「scott」とパスワード「tiger」を変更することは困難です。この情報へのアクセス権を持っているユーザーは誰でも、権限を使用してシステムに侵入できます。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

...
NSString encryptionKey = "lakdsljkalkjlksdfkl";
...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号鍵をハードコーディングするのはよくない発想です。暗号鍵をハードコーディングするとプロジェクトの開発者全員が暗号鍵を見ることができるだけでなく、問題の修復も非常に困難です。コードが実運用に入ると、ソフトウェアにパッチを当てない暗号鍵を変更できません。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。
例 1: 次のコードは、ハードコーディングされている暗号鍵を使用して、情報を暗号化します。

...
$encryption_key = 'hardcoded_encryption_key';

//$filter = new Zend_Filter_Encrypt('hardcoded_encryption_key');
$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは暗号化鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされた暗号化鍵 ('hardcoded_encryption_key') を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、この暗号化鍵を使用してシステムによって暗号化されているデータを危険な状態におくことがあります。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。



このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号鍵をハードコーディングするのはよくない発想です。暗号鍵をハードコーディングするとプロジェクトの開発者全員が暗号鍵を見ることができるだけでなく、問題の修復も非常に困難です。コードが実運用に入ると、ソフトウェアにパッチを当てない暗号鍵を変更できません。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。
例 1: 次のコードは、ハードコーディングされている暗号鍵を使用して、情報を暗号化します。

...
from Crypto.Ciphers import AES
encryption_key = b'_hardcoded__key_'
cipher = AES.new(encryption_key, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは暗号化鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、基本的にハードコーディングされた暗号化鍵 _hardcoded__key_ を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、この暗号化鍵を使用してシステムによって暗号化されているデータを危険な状態におくことがあります。

暗号鍵をハードコーディングするのはよくない発想です。暗号鍵をハードコーディングするとプロジェクトの開発者全員が暗号鍵を見ることができるだけでなく、問題の修復も非常に困難です。コードが実運用に入ると、ソフトウェアにパッチを当てない暗号鍵を変更できません。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。
例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

require 'openssl'
...
encryption_key = 'hardcoded_encryption_key'
...
cipher = OpenSSL::Cipher::AES.new(256, 'GCM')
cipher.encrypt
...
cipher.key=encryption_key
...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは暗号化鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、基本的にハードコーディングされた暗号化鍵 "hardcoded_encryption_key" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、この暗号化鍵を使用してシステムによって暗号化されているデータを危険な状態におくことがあります。

暗号鍵をハードコーディングするのはよくない発想です。暗号鍵をハードコーディングするとプロジェクトの開発者全員が暗号鍵を見ることができるだけでなく、問題の修復も非常に困難です。コードが実運用に入ると、ソフトウェアにパッチを当てない暗号鍵を変更できません。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

...
let encryptionKey = "YELLOW_SUBMARINE"
...

例 2: 次のコードは、ハードコーディングされている暗号鍵を使用して AES 暗号化を行っています。

...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"YELLOW_SUBMARINE",
16,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号化キーはハードコーディングしないでください。これにより、暗号化キーがプロジェクトの開発者全員に見えてしまい、問題の修正が極めて困難になるためです。コードの運用後に暗号鍵を変更するには、ソフトウェア パッチが必要です。暗号鍵が保護するアカウントが危険にさらされると、組織はセキュリティとシステム可用性のいずれかを選択することを迫られます。

例 1: 次の例は、.pem ファイル内の暗号鍵を示しています。

...
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQCtVacMo+w+TFOm0p8MlBWvwXtVRpF28V+o0RNPx5x/1TJTlKEl
...
DiJPJY2LNBQ7jS685mb6650JdvH8uQl6oeJ/aUmq63o2zOw=
-----END RSA PRIVATE KEY-----
...

このコードにアクセスできる全員が、暗号鍵を閲覧できます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。アプリケーションの実行可能ファイルにアクセスできる攻撃者は、暗号鍵の値を抽出できます。

暗号鍵をハードコーディングすることは推奨されません。これによりプロジェクトの開発者全員が暗号鍵を見ることができ、問題の修復が非常に困難になるためです。 コードが実運用に入ると、暗号鍵を変更するにはソフトウェアパッチが必要になります。この暗号鍵によって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされている暗号鍵を使用しています。

...
Dim encryptionKey As String
Set encryptionKey = "lakdsljkalkjlksdfkl"
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
  AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
  ...
Exit Sub
...

このコードにアクセスできる全員が、暗号鍵にアクセスすることができます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入できます。さらに、攻撃者がアプリケーションの実行可能ファイルにアクセスできれば、暗号鍵の値を解読できます。

暗号化キーはハードコーディングしないでください。これにより、暗号化キーがプロジェクトの開発者全員に見えてしまい、問題の修正が極めて困難になるためです。コードの運用後に暗号鍵を変更するには、ソフトウェア パッチが必要です。暗号鍵が保護するアカウントが危険にさらされると、組織はセキュリティとシステム可用性のいずれかを選択することを迫られます。

例 1: 次の例は、Ruby on Rails 構成の secrets.yml ファイル内の暗号化キーを示しています。

...
production:
  secret_key_base: 0ab25e26286c4fb9f7335947994d83f19861354f19702b7bbb84e85310b287ba3cdc348f1f19c8cdc08a7c6c5ad2c20ad31ecda177d2c74aa2d48ec4a346c40e
...

このコードにアクセスできる全員が、暗号鍵を閲覧できます。アプリケーションが頒布された後は、プログラムにパッチを適用しない限り、暗号鍵を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。アプリケーションの実行可能ファイルにアクセスできる攻撃者は、暗号鍵の値を抽出できます。

HMAC 鍵をハードコーディングするのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵のハードコーディングによって、ソースにアクセスできる誰もがそれを表示できるようになり、この関数の暗号化強度が損なわれます。
例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
             Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
  EXPORTING
    if_algorithm = 'SHA3'
    if_key       = 'secret_key'
  RECEIVING
    ro_object    = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされた HMAC キー "secret_key" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

HMAC 鍵をハードコーディングするのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵のハードコーディングによって、ソースにアクセスできる誰もがそれを表示できるようになり、この関数の暗号化強度が損なわれます。
例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
  string hmacKey = "lakdsljkalkjlksdfkl";
  byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
  hmac.Key = keyBytes;
  ...
}

このコードは正常に実行されますが、このコードにアクセスしたユーザーは HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされた HMAC キー "hmacKey" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

HMAC 鍵を決してハードコーディングしないでください。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵のハードコーディングによって、ソースにアクセスできる誰もがそれを表示できるようになり、この関数の暗号化強度が損なわれます。

例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

import "crypto/hmac"
...
hmac.New(sha256.New, []byte("secret"))
...

このコードは正常に実行されますが、ソースにアクセスできるユーザーは HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、基本的に、ハードコーディングされた HMAC 鍵 "secret" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

HMAC 鍵をハードコーディングするのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵をハードコーディングすると、ソースにアクセスできる人なら誰でもそれを利用できるようになり、この関数の暗号化強度が損なわれます。
例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

const hmacKey = "a secret";
const hmac = createHmac('sha256', hmacKey);
hmac.update(data);
...

このコードは正常に実行されますが、ソースにアクセスできる人なら誰でも HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされた hmacKey を変更できないと考えられます。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

HMAC 鍵をハードコーディングするのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵のハードコーディングによって、ソースにアクセスできる誰もがそれを表示できるようになり、この関数の暗号化強度が損なわれます。

例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

...
CCHmac(kCCHmacAlgSHA256, "secret", 6, plaintext, plaintextLen, &output);
...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、基本的に、ハードコーディングされた HMAC キー "secret" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

HMAC 鍵をハードコーディングするのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵のハードコーディングによって、ソースにアクセスできる誰もがそれを表示できるようになり、この関数の暗号化強度が損なわれます。

例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

import hmac
...
mac = hmac.new("secret", plaintext).hexdigest()
...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、基本的に、ハードコーディングされた HMAC キー "secret" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

HMAC 鍵をハードコーディングするのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵のハードコーディングによって、ソースにアクセスできる誰もがそれを表示できるようになり、この関数の暗号化強度が損なわれます。
例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

...
digest = OpenSSL::HMAC.digest('sha256', 'secret_key', data)
...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされた HMAC キー "secret_key" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

HMAC 鍵をハードコーディングするのはよくない発想です。HMAC の暗号化の強度は、メッセージ認証値の計算と検証に使用される秘密鍵の機密性に依存します。HMAC 鍵のハードコーディングによって、ソースにアクセスできる誰もがそれを表示できるようになり、この関数の暗号化強度が損なわれます。

例 1: 次のコードでは、ハードコーディングされている鍵で HMAC を計算しています。

...
CCHmac(UInt32(kCCHmacAlgSHA256), "secret", 6, plaintext, plaintextLen, &output)
...

このコードは正常に実行されますが、このコードにアクセスしたユーザーは HMAC 鍵にアクセスできます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、基本的に、ハードコーディングされた HMAC キー "secret" を変更することはできません。不心得な従業員がこの情報へのアクセス権を持っている場合、HMAC 関数の安全性が損なわれる可能性があります。

空の値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡すことは推奨されません。このシナリオでは、導出鍵は指定された salt のみに基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限り空のパスワードは変更できません。空のパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされた値をパスワード引数として PBKDF に渡します。

...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("password", salt,100000);
...

コードにアクセスできれば、ハードコーディングされたパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、ハードコーディングされたパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされたパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、ハードコーディングされたパスワードが使われている証拠を割り出すことが可能です。

ハードコーディングされた値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡さないでください。このシナリオでは、導出鍵は指定された salt にほぼ基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限りハードコーディングされたパスワードは変更できません。ハードコーディングされたパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされた値をパスワード引数として PBKDF に渡します。

const pbkdfPassword = "a secret";
crypto.pbkdf2(
    pbkdfPassword,
    salt,
    numIterations,
    keyLen,
    hashAlg,
    function (err, derivedKey) { ... }
)

コードにアクセスできれば誰でも、ハードコーディングされたパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、ハードコーディングされたパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされたパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、ハードコーディングされたパスワードが使われている証拠を割り出すことが可能です。

ハードコーディングされた値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡さないでください。このシナリオでは、導出鍵は指定された salt にほぼ基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限りハードコーディングされたパスワードは変更できません。ハードコーディングされたパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされた値をパスワード引数として PBKDF に渡します。

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     "secret",
                     6,
                     salt,
                     saltLen
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

コードにアクセスできれば、ハードコーディングされたパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、ハードコーディングされたパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされたパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、ハードコーディングされたパスワードが使われている証拠を割り出すことが可能です。

ハードコーディングされた値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡さないでください。このシナリオでは、導出鍵は指定された salt にほぼ基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限りハードコーディングされたパスワードは変更できません。ハードコーディングされたパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされた値をパスワード引数として PBKDF に渡します。

...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "hardcodedpassword");
...

コードにアクセスできれば、ハードコーディングされたパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることが誰にでも判別できます。さらに、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性があります。攻撃者が、ハードコーディングされたパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされたパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、ハードコーディングされたパスワードが使われている証拠を割り出すことが可能です。

ハードコーディングされた値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡さないでください。このシナリオでは、導出鍵は指定された salt にほぼ基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限りハードコーディングされたパスワードは変更できません。ハードコーディングされたパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされた値をパスワード引数として PBKDF に渡します。

from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', 'password', salt, 100000)
...

コードにアクセスできれば、ハードコーディングされたパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、ハードコーディングされたパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされたパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、ハードコーディングされたパスワードが使われている証拠を割り出すことが可能です。

ハードコーディングされた値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡さないでください。このシナリオでは、導出鍵は指定された salt にほぼ基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限りハードコーディングされたパスワードは変更できません。ハードコーディングされたパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされた値をパスワード引数として PBKDF に渡します。

...
key = OpenSSL::PKCS5::pbkdf2_hmac('password', salt, 100000, 256, 'SHA256')
...

コードにアクセスできれば、ハードコーディングされたパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、ハードコーディングされたパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされたパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、ハードコーディングされたパスワードが使われている証拠を割り出すことが可能です。

ハードコーディングされた値をパスワード引数としてパスワードベースの暗号鍵導出関数 (PBKDF) に渡さないでください。このシナリオでは、導出鍵は指定された salt にほぼ基づくことになり (鍵は著しく脆弱になる)、そうなった場合にこの問題を修正するのは非常に困難です。有害なコードが実運用に入ると、多くの場合、ソフトウェアにパッチを当てない限りハードコーディングされたパスワードは変更できません。ハードコーディングされたパスワードに基づいて導出した鍵で保護されるアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。

例 1: 次のコードは、ハードコーディングされた値をパスワード引数として PBKDF に渡します。

...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"secret",
6,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...

コードにアクセスできれば、ハードコーディングされたパスワード引数に基づいてコードから暗号鍵が 1 つ以上生成されることを判別できる上に、初歩的なクラック技法を使用できれば、不正な鍵で保護されているどのリソースにもアクセスできる可能性が高まります。攻撃者が、ハードコーディングされたパスワードに基づく鍵の生成に使用される salt 値にもアクセスできれば、それらの鍵のクラッキングは容易になります。プログラムが頒布された後は、プログラムにパッチを適用しない限り、ハードコーディングされたパスワードを変更できないと考えられます。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにさえアクセスできれば、ハードコーディングされたパスワードが使われている証拠を割り出すことが可能です。