いいえ!
パスワード(またはまだ機密性の高いパスワードハッシュ)を保存する余分な場所はすべて、漏洩する可能性のある別の場所です。これがSSLページがキャッシュされない理由の1つです。機密情報をキャッシュしてはならないためです。
優れた認証コード(SSHで見られるようなもの)は、パスワードがスワップ不可として保存されているメモリ領域をマークして、オペレーティングシステムがディスクに書き込めないようにする作業にも使用されます。
このキャッシュから機密データが漏洩するリスクは低いかもしれませんが、これを行うことでリスクが高まります。このデータをローカルPHPファイルに配置することで、ローカルファイルインクルードの脆弱性からアクセスできるようになります。実際にパスワードを画面にエコーアウトするには、ローカルファイルを含めるだけでは不十分な場合があります。このキャッシュが存在する前は、パスワードハッシュにアクセスするために、SQLインジェクションの脆弱性または完全なサーバーの侵害がおそらく必要でしたが、今ではそれらとローカルファイルインクルードがハッシュにアクセスできます。
ページの読み込み速度を向上させるために、機密性の低い他のデータを複数の場所に保存することは問題ありませんが、パスワードとパスワードハッシュは立ち入り禁止にする必要があります。
認証トークンを保存することで、認証されたユーザーのページが読み込まれるたびにパスワードハッシュを計算して検索する必要がなくなります。これは、ログイン時にランダムに生成され(したがって、予測が困難です)、短命である必要があります。これはまさにPHPセッションIDであり、パスワードを比較する最初のチェックの後で、ユーザーが適切に認証されていることを確認するのに完全に適切です。
データベースにクエリを実行し、ページが読み込まれるたびにパスワードハッシュを計算する場合は、クライアントのどこかに、おそらくCookieにパスワード(または場合によってはパスワードハッシュ)を保存しておく必要があり、この機密データが送信されていることに気付きました。すべてのページリクエストに対してインターネット経由で。これは一般的に悪い習慣であり、すべてのページにSSLを使用していない限り、パスワード(またはパスワードハッシュ)がユーザーのハードドライブに保存され、中間プロキシになる可能性があります。
PS
ローカルファイルを含めることが、データベースからの単純なKey-Valueルックアップよりも著しく高速である理由に興味があります。私の推測では、ネットワークでひどい遅延が発生しているか、ユーザーテーブルで競合が発生しています。どちらかが本当に修正する必要があります。