Password Management: Hardcoded Password

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
password = 'tiger'.
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、パスワード「tiger」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
URLRequestDefaults.setLoginCredentialsForHost(hostname, "scott", "tiger");
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイナリにアクセスできる場合、数多くある公的に入手可能な逆コンパイラのいずれか 1 つを使用することによって、使用されるパスワードの値を含んでいる逆アセンブルされたコードにアクセスできます。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

例 1: 次のコードは、Hardcoded Password を使用してクライアント証明書を認証します。

...
HttpRequest req = new HttpRequest();
req.setClientCertificate('mycert', 'tiger');
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。この情報へのアクセス権があるユーザーは誰でも、権限を使用してシステムに侵入できます。プログラムがリリースされた後で、証明書のパスワードを変更することは困難です。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
NetworkCredential netCred =
           new NetworkCredential("scott", "tiger", domain);
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布されると、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つネットワーク認証情報ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者がアプリケーションの実行可能ファイルにアクセスできる場合、使用されるパスワードの値が含まれているコードを逆アセンブルすることができます。

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
rc = SQLConnect(*hdbc, server, SQL_NTS, "scott",
                SQL_NTS, "tiger", SQL_NTS);
...

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

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
MOVE "scott" TO UID.
MOVE "tiger" TO PASSWORD.
EXEC SQL
  CONNECT :UID
  IDENTIFIED BY :PASSWORD
  AT :MYCONN
  USING :MYSERVER
END-EXEC.
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
<cfquery name = "GetSSNs" dataSource = "users"
 username = "scott" password = "tiger">
SELECT   SSN
FROM     Users
</cfquery>
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
var password = "foobarbaz";
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイトコードにアクセスできる場合、javap -c コマンドを使用すると、使用されるパスワードの値を含んで逆アセンブルされたコードにアクセスできます。Example 1 の場合、この操作の結果は次のようになります。

javap -c ConnMngr.class

22: ldc   #36; //String jdbc:mysql://ixne.com/rxsql
24: ldc   #38; //String scott
26: ldc   #17; //String tiger

Hardcoded Password はシステムのセキュリティを危険にさらすことがありますが、この問題への対策は簡単ではありません。

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

password := "letmein"
...
response.SetBasicAuth(usrName, password)

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、パスワード「tiger」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイナリにアクセスできる場合、数多くある公的に入手可能な逆コンパイラのいずれか 1 つを使用することによって、使用されるパスワードの値を含んでいる逆アセンブルされたコードにアクセスできます。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
obj = new XMLHttpRequest();
obj.open('GET','/fetchusers.jsp?id='+form.id.value,'true','scott','tiger');
...

このコードは正常に実行されますが、含まれる Web ページにアクセスする全員がパスワードを閲覧できます。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は困難です。

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

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

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

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
DriverManager.getConnection(url, "scott", "tiger")
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイトコードにアクセスできる場合、javap -c コマンドを使用すると、使用されるパスワードの値を含んで逆アセンブルされたコードにアクセスできます。Example 1 の場合、この操作の結果は次のようになります。

javap -c ConnMngr.class

22: ldc   #36; //String jdbc:mysql://ixne.com/rxsql
24: ldc   #38; //String scott
26: ldc   #17; //String tiger

モバイル環境では、デバイスをなくす機会が高いことを考慮すると、パスワード管理は特に重要です。
例 2: 次のコードは、ハードコーディングされたユーザー名とパスワードを使用して、Android WebView で保護されたページを表示するための Authentication を設定します。

...
webview.webViewClient = object : WebViewClient() {
    override fun onReceivedHttpAuthRequest( view: WebView,
        handler: HttpAuthHandler, host: String, realm: String
    ) {
        handler.proceed("guest", "allow")
    }
}
...

Example 1 と同様に、このコードは問題なく動作しますが、コードへのアクセス権限を持つ誰もがパスワードにアクセスできます。

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

例 1: 次のコードは、Hardcoded Password を使用してデータベースに接続します。

...
rc = SQLConnect(*hdbc, server, SQL_NTS, "scott",
                SQL_NTS, "tiger", SQL_NTS);
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにのみアクセスできれば、パスワードの値を抽出できます。

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
$link = mysql_connect($url, 'scott', 'tiger');
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

DECLARE
    password VARCHAR(20);
BEGIN
    password := "tiger";
END;

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、パスワード「tiger」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイナリにアクセスできる場合、数多くある公的に入手可能な逆コンパイラのいずれか 1 つを使用することによって、使用されるパスワードの値を含んでいる逆アセンブルされたコードにアクセスできます。

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

password = "tiger"
...
response.writeln("Password:" + password)

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、パスワード「tiger」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイナリにアクセスできる場合、数多くある公的に入手可能な逆コンパイラのいずれか 1 つを使用することによって、使用されるパスワードの値を含んでいる逆アセンブルされたコードにアクセスできます。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
Mysql.new(URI(hostname, 'scott', 'tiger', databasename)
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。Ruby はインタープリター言語であるため、このアプリケーションを他のユーザーが実行できる場合、それは攻撃者がソースにアクセスできることを意味します。そのため、本番ソフトウェアに持ち込まないことが非常に重要になります。ネイティブ コードにコンパイルできる Ruby 実装を使用している場合、または Ruby への C 拡張を作成している場合でも、バイナリを調べれば情報を取得できるため、暗黙的に信頼してはいけません。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
ws.url(url).withAuth("john", "secret", WSAuthScheme.BASIC)
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布されると、プログラムにパッチを適用しない限り、基本的に「secret」というパスワードを持つデータベース ユーザー「john」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイトコードにアクセスできる場合、javap -c コマンドを使って、使用パスワードの値を含んでいる逆アセンブルされたコードにアクセスできます。Example 1 の場合、この操作の結果は次のようになります。

javap -c MyController.class

24: ldc   #38; //String john 
26: ldc   #17; //String secret 

ハードコーディングされたパスワードはシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

例 1: 次のコードは、Hardcoded Password を使用してデータベースに接続します。

...
let password = "secret"
let username = "scott"
let con = DBConnect(username, password)
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。攻撃者はアプリケーションの実行可能ファイルにのみアクセスできれば、パスワードの値を抽出できます。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は困難です。

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

例 1: 次の URL は、ハードコーディングされたパスワードを使用しています。

...
https://user:secretpassword@example.com
...

例 2: 次の ODBC 接続文字列は、ハードコーディングされたパスワードを使用しています。

...
server=Server;database=Database;UID=UserName;PWD=Password;Encrypt=yes;
...

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。

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

...
Dim con As New ADODB.Connection
Dim cmd As New ADODB.Command
Dim rst As New ADODB.Recordset

con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=tiger;"
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。さらに悪いことに、攻撃者がアプリケーションのバイナリにアクセスできる場合、数多くある公的に入手可能な逆コンパイラのいずれか 1 つを使用することによって、使用されるパスワードの値を含んでいる逆アセンブルされたコードにアクセスできます。

Hardcoded Password はシステムのセキュリティを危険にさらす可能性があり、この問題への対策は困難です。

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

...
credential_settings:
  username: scott
  password: tiger
...

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