|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #8827 PHP_AUTH_PW stores password when using External Authentication
Submitted: 2001-01-21 01:41 UTC Modified: 2010-12-31 20:17 UTC
Avg. Score:4.8 ± 0.4
Reproduced:4 of 4 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: csy at hjc dot edu dot sg Assigned: jani (profile)
Status: Closed Package: Apache related
PHP Version: 4.0.4pl1 OS: Redhat Linux 6.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: csy at hjc dot edu dot sg
New email:
PHP Version: OS:


 [2001-01-21 01:41 UTC] csy at hjc dot edu dot sg
Under Apache-1.3.14 w/ php4.0.4pl1 and using auth_ldap for external authentication to an ldap server, PHP_AUTH_PW stores the password of the user that authenticates successfully.

This did not occur in earlier versions of php3 and php4 and creates a problem for websites that require external authentication before accessing and the services that are provided within the websites are run by different parties as this will result in other parties getting hold of the user's password.

php.ini used is similar to that which came with the php-4.0.4pl1 distribution and no settings that are changed is related to authentication.

php is compiled using the following parameters :-



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-04-16 06:41 UTC]
This is now the expected behaviour due to various problems with being able to verify if there are other mecanisms. If you really dont want this to happen run in safe mode or manually patch your mod_php4.c and uncommect the line

&& auth_type(r)

this is a very buggy fix for various reasons when other mod_auth_* systems decline authentication it will onyl work when they accept.

- James
 [2001-04-17 04:53 UTC] csy at hjc dot edu dot sg
I am currently running with safe_modes enabled but the password is still retrievable via the PHP_AUTH_PW variable when using external authentications.

 [2001-04-28 16:12 UTC]
This is the expected behaviour now.

HTTP_RAW_HEADERS holds the same information anyway.

- James
 [2001-04-28 23:09 UTC] csy at hjc dot edu dot sg
Isn't this going to be a big security problem for portal sites using PHP which have a common user base and separate groups of developers developing and selling online service?

As a malicious group of developers would be able to capture the password and assume the identity of the user and go around "patronising" other services.

How about having a general configuration parameter that disables the storage of the password in PHP_AUTH_PW and HTTP_RAW_HEADERS without having the need for PHP to autodetect for external authentications?

Something like a STORE_PASSWORD = false flag in php.ini which the administrator needs to manually set to on or off.

 [2001-06-09 23:52 UTC]
This is the correct behaviour the information is avalible via the raw headers anyway.

- James
 [2001-06-10 15:22 UTC] csy at hjc dot edu dot sg
I understand about the raw headers. Which is why I am suggesting if it would be possible to have an administrator configurable flag to enable/disable PHP storing the password in PHP_AUTH_PW .

Assumung that the web server only runs PHP with no CGI and such, it would be pretty difficult(?) for unauthorised users to extract the password from the raw headers. But PHP happily stores it in a variable and allows any programmer to access it.

 [2002-12-04 10:49 UTC]
I believe this was fixed in 4.3.0, can someone confirm (Jani)?
 [2010-12-31 20:17 UTC]
-Status: Open +Status: Closed -Package: Feature/Change Request +Package: *General Issues -Assigned To: +Assigned To: jani
 [2010-12-31 20:17 UTC]
-Package: *General Issues +Package: Apache related
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Feb 22 05:01:28 2024 UTC