web-dev-qa-db-ja.com

mysqlパスワードをプレーンテキストで構成ファイルに保存するよりも優れたアプローチですか？

多くのPHPプログラムでは、mysqlパスワードをプレーンテキスト（文字列または定数）で、アプリケーションのルートにある構成ファイルに保存する必要があります。

ここ数年の間に、これに対するより良いアプローチはありますか？

これまでのところ、2つの最小限のセキュリティブーストを考え出しました。

  1. .htaccessのルールを使用してWeb経由でファイルを読み取れないようにします（phpが失敗した場合、またはphpソースを読み取るためのセキュリティ脆弱性がある場合）

  2. db接続が行われた（設定解除された）後、メモリ内のパスワードを破棄します（セキュリティ違反、インジェクションなどによる文字列のダンプを防止するため）。

もちろん、どちらも元の問題を解決しません。

他のアイデアをありがとう！

phpmysqlsecuritypasswords
38
ck_

コードにはパスワードが必要になるため、完全なセキュリティはありません。しかし、回復を困難にすることができます。

私はいくつかのハッシュをWeb構成に環境変数として入れて、_MYSQL_PASS_HASH_と言います

次に、md5(getenv('MYSQL_PASS_HASH').'gibberish$qwefsdf')のようなものを実行します。これがパスワードになります。もちろん、偏執狂であれば、その後unsetenvを実行する必要があります。

あなたのパスワードは文字通りどこかに保存されることはなく、誰かがあなたの両方のウェブ設定を持っているときにのみ回復することができますandデータベースに含まれています。

これは、webrootの外部のファイルで発生します（_.htaccess_を信頼しないでください）。

12
mvds

個人的には、データベース接続の詳細などの機密情報を、Webフォルダーのルート外のconfig.iniファイルに保存しています。次に、私のindex.phpで次のことができます：

$config = parse_ini_file('../config.ini');

これは、サーバーが誤ってPHPスクリプトをプレーンテキストとして出力し始めた場合（以前はFacebookで悪名高いものでした）、変数が表示されないことを意味します）PHPスクリプトは変数にアクセスできます。

。htaccessファイルが移動または破棄された場合に不測の事態が発生しない。htaccessにも依存しません。

警告、2017年2月14日追加：このような構成パラメーターを環境変数として保存します。 。iniファイルアプローチをしばらく使用していません。

25
Martin Bean

構成ファイルをドキュメントルートの外に置くことは、構成ファイルのセキュリティを向上させる一般的な方法です。

12
Paul Dragoonis

確かに、ドキュメントルート内のプレーンテキストファイルにパスワードを保存しないでください。それを保護するために実行する追加の手順は、Webサーバーを構成するために必要なアクセスレベルによって異なります。

パスワードはphp.iniで（またはApache構成または.htaccessのini設定を介して）定義できます。または、ウェブサーバーを起動するときに環境に設定します。

パスワードを暗号化するだけでは意味がありません。つまり、クォーラム認証でユーザー指定のパスワードを使用してパスワードを復号化しない限り、復号化キーを保存する必要があります（ただし、これにより、認証されていないセッションがdbにアクセスできなくなり、乱雑になります。新しいユーザーをクォーラムに追加する必要があります）。

安価なホスティングパッケージで、ドキュメントルートの外部にアクセス可能なストレージがない場合、phpのインクルードファイルにパスワードを保存すると、そのファイルが公開されないようにする必要があります（ファイルはダウンロードされる代わりにphpによって解析されます）。または、単にファイルの先頭に「.ht」を付けると、リモートアクセスができなくなる場合があります。

2番目のオプションは多少冗長であることに注意してください。誰かがあなたのコードにそのような大きなダメージを与えることができる場合、実行中のコードからパスワードを抽出する必要はありません。

本当に問題の解決策はありません。

C.

2
symcbean

この機密データを適切に保存するほかに、必要なデータベースのみを含む 別のMySQLユーザーを作成する 必要な 特権とアクセスを制限する が必要ですへのアクセス。また、データベースサーバーはWebサーバーと同じマシンで実行されることが多いため、ローカルアクセスへのアクセスも制限してください。したがって、単一のデータベース/テーブルからデータを読み取るだけの場合は、root権限を持つユーザーを使用しないでください。

2
Gumbo

ファイルのセキュリティと可用性を犠牲にしてもかまわない場合は、構成ファイルからパスワードを取り出し、管理者に起動時に入力してグローバル変数に格納するように要求できます。

その変数をダンプする可能性のあるインジェクション攻撃から安全であることを確認する必要があります。もちろん、（再）ブートプロセスに手動のステップがあります。

1
G__

ウェブルートにある必要はありません。ファイルをウェブルートの外に移動して、そのように呼び出すことができます。これは、ファイルをWebから直接呼び出すことができないことを意味します。

GETデータからのフィルタリングを行わずにコードを含めるなど、コードにセキュリティ上の欠陥がある場合、そのファイルは依然として危険にさらされています。本当の鍵は、アプリケーションも同様に安全であることを確認することです。

0
Jim W.