こんにちはセキュリティ意識の人々、データベース接続を作成する際に、ハードコードされた資格情報の危険性はありますか？
私は最近、静的コード分析のためのツールで自分のアプリケーションをスキャンしていると、重大度の高い調査結果の一つは、接続を作成するためのハードコードされたユーザー名とパスワードです：
dm.getConnection(databaseUrl,"server","revres");
なぜスキャナはこれがアプリケーションのリスクであると考えていますか？パスワードが侵害された場合に簡単にパスワードを変更できないなどの短所があります。理論的に誰かがバイナリをリバースエンジニアリングして資格情報を知ることができます。しかし、私は、暗号化されていない限り、資格情報を設定ファイルに保存する利点は見当たりません。暗号化すれば、暗号化キーで同じ問題を解決できます...
私には見えないリスクがありますか？あるいは、私はまったく別のアプローチをとるべきですか？ ありがとうございます。
私はそれがあなたのソースコードやコンパイルされたコードのアクセス可能性/安全性に依存すると思います。開発者は通常、デベロッパーボックスにコードのコピーを持っています。デベロッパーボックスは通常、本番サーバーほど安全ではないため、はるかに簡単にハッキングされます。一般に、テスト用のuser/pwはdevボックスに設定されており、実際のpwはより安全な設定ファイルに格納されています。はい、誰かがサーバーにハッキングした場合、資格情報を簡単に取得できますが、それはほとんどの場合、devボックスに入るよりもはるかに困難です。しかし、私はそれが依存していると言いました。デベロッパーが1人しかなく、スーパーセキュアマシンを持っていて、コードのレポもスーパーセキュアであれば、効果的な違いはありません。
私が行うことは、エンドユーザーに最初に資格情報を要求してから、それらを暗号化してファイルに保存することです。この方法では、私は接続の詳細とパスワードを開発者として知らない。キーはハッシュされたバイナリです。そして、その間にekstraバイトを突き刺すことで格納します。クラックしたい人は、使用されているアルゴリズム、キーとベクトルの長さ、それらの位置、値を保持しているバイトシーケンスの開始位置を見つけるべきです。この情報をすべて取得するために自分のコードをリバースエンジニアにする天才も、それに侵入します（ただし、エンドユーザーの資格情報を直接破る方が簡単かもしれません）。
私は理由をdownvoterに尋ねるでしょう。 SOは理由なしにダウンボートを許可すべきではありません。それは防衛のない執行のようなものであり、一般的に何が意味されているかを理解していない人は、そうすることができるからです。 –
コードに埋め込まれた固定パスワードは、すべてのインストールで同じで、ソースコードまたはバイナリ（インストールメディアを含む）へのアクセス権を持つ誰でもアクセスできます。
ファイルから読み取ったパスワードは、インストールごとに異なる可能性があり、パスワードファイルを読み取ることができるユーザーにのみ知られています。
通常、インストーラーはサイトごとに一意のパスワードを生成し、アプリケーションに読み込まれるファイルに安全に書き込みます。 （「安全に」とは、シンボリックリンクの攻撃を防ぐためにO_CREAT|O_EXCLを使用し、誰かがそれを開く前にファイルの場所と権限を正しく選択していることを意味します）。
これは興味深いものですが、私は実行中の環境やテクノロジを指定していないので、.Netアプリケーションの例を挙げることができます。私の推測はJavaですが？私はこれが依然として関連性があり、あなたを助けることを望みます。
私の主なアドバイスは、この記事を読んで、そこから行くことであろう。ここではProtecting Connection information - MSDN
は、私は、これは暗号化されたコンフィギュレーションファイルとWindows認証を使用して、両方を解決し見てきましたworking with encrypted configuration files here
を説明するページです。私は、関連するストアドプロシージャなどへのアクセスを許可されるユーザーとしてアプリケーションを実行すること（可能な限り少ない、たとえばPrinciple of Least Privilege）、さらにフォルダへのアクセスなどは良いルートだと私は思っています。
両方の方法を使用することをお勧めします。これは、IISのプールに関連するローカルフォルダへのアクセス権を与え、ユーザーアクセスをSQLなどに分割することができるためです。
これはアプリケーションのニーズにもよりますが、設定ファイルや環境ユーザーアカウントを使ってこれを設定できる主な理由は、アプリケーションを本番環境に公開するときに、開発者は運用ユーザーアカウント情報にアクセスする必要はなく、代わりにローカル/システムテスト/ UAT資格情報
もちろん、GITのような私設分散型ネットワークでホストすると、これが危険にさらされる可能性があり、ハッカーが資格情報にアクセスする可能性があるソース制御チェックインのプレーンテキストに格納されません。
これは私が思っていたものですが、私は確信していました。これは私が責任を負っている小さなアプリケーションなので、リスクは私の意見ではあまり高くありません。もちろん、静的コード分析ツールは、DEVチームのサイズや異なる環境のセキュリティレベル（私はDEV、UAT、PRODを使用します）などの要因を考慮に入れることはできません。したがって、重大度の分類はおそらくそれが前提大規模なエンタープライズアプリケーションです。 – Pepa