6

When using basic authentication (specifically via LDAP, but htpasswd also) with Apache, it makes the REMOTE_USER variable available to the PHP / Ruby / Python code underneath -- this is very useful for offloading authentication to the webserver.

In our office environment we have lots of internal applications working like this over SSL, all quite secure. BUT: Apache exposes the PHP_AUTH_USER (=REMOTE_USER) and PHP_AUTH_PW variables to any application inside PHP. (PHP_AUTH_PW contains the plaintext password the user entered.) This means it's possible for the app to harvest usernames and passwords. Presumably the same information is available to Python and Ruby (all three are currently in use; PHP is being phased out).

So how can I prevent Apache from doing this?

One idea is to use Kerberos Negotiate authentication (which does not expose the password and has the benefit of being SSO), but that automatically falls back to Basic for some browsers (Chrome and in some cases Firefox), causing the password to be exposed again.

4 Answers 4

4

Just in case someone stumble on this question like i did:

In Apache 2.4.5 and later you can use the AuthBasicFake directive to mask the password:

AuthBasicFake toto tata

Results in:

PHP_AUTH_USER=toto
PHP_AUTH_PWD=tata

To keep the username:

AuthBasicFake %{REMOTE_USER} tata

results in:

PHP_AUTH_USER=value-of-remote-user 
PHP_AUTH_PWD=tata

REMOTE_USER is not affected.

1
  • Almost 10 years to hit the same problem again, luckily there's a better answer now :) Apr 14, 2020 at 14:07
2

Seems not possible but see http://bytes.com/topic/php/answers/798619-prevent-setting-php_auth_pw
Post #8 suggest to use auto_prepend_file to run a script that unset the variable
It's a workaround not a clean solution but it exist...

Did you try AuthType Digest ?

1
  • Unfortunately LDAP doesn't support Digest Jun 6, 2010 at 11:49
2

Radius is right -- you can't.

After further research I realised that this is basically a text-book scenario for an identity assertion: A trusted identity provider "proves" the user's identity to the client application. The SAML 2.0 specification seems a good fit.

I was hoping to get away without more infrastructure layers, but I'm going to go with simpleSAMLphp[1] for the IDP and mod_mellon[2] for the Apache side. (A day's worth of tinkering and it works.) This doesn't solve the password problem, but moves it to where it can be controlled.

Aside: Sun's OpenSSO is quite beefy but Oracle killed it and the related OpenAM project's future is still not clear.

[1]: http://rnd.feide.no/simplesamlphp simpleSAMLphp

[2]: http://code.google.com/p/modmellon/ mod_mellon

2
  • Radius is'n 100% right. You can prevent using password authentication by server using mod_auth_kerb and setting KrbMethodK5Passwd off
    – sumar
    Jan 14, 2011 at 11:35
  • That would lock out users of some browsers, which I don't want to do. Feb 15, 2011 at 12:03
1

I have a work-around. I added the following to my .htaccess

php_value auto_prepend_file "global_prepend.php"

In the file "global_prepend.php" I added the following PHP line:

$_SERVER["PHP_AUTH_PW"]="Shh! It's a secret!";

I can now login with my credentials and my real password is no longer stored.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .