Are all Web Passwords ultimately plaintext?

I have installed a web server and I am using PHP authentication with and LDAP server (although I haven't got the box login with LDAP to work yet - but that is another story).

Anyway, I am shocked by the fact that the password coming in from PHP_AUTH_PW is in plaintext. I am becoming fearful that this must be so. From what I understand, all of the encrypted methods of storing passwords (flat files, database, ldap, whatever), use server side encryption and as these are generally one-way hashes, the plaintext must be available to them.

So, here is what seems shocking to me - while I recognize that somebody with root permission has access to my password, they only have access if they rewrite the getty daemon and such. With the web, it seems like any two bit php hack with access to my php authentication script can save users passwords when they are entered.

Essentially, this means that anybody with root access to a box (I am at a university, so a student sysadmin help would be a good example), can very simply acquire the passwords that any users might use to log into the web via ldap. If this same user uses the same password on another system (like where the students grades are entered), then the student sysadnin would have full access to the users account on a system where they aren't sysadmin.

Admittedly, using the same password on different systems has been stated as a bad idea, but I was rather shocked to recognize just how bad an idea it was.

Am I missing anything here? Is there anyway to secure the password itself from the system administrator?

Secure passwords are stored as a one-way encrypted hash, but are vulnerable to dictionary attacks. *nix and Windows both store user passwords via some sort of one-way hash scheme, but many applications simply store the password (including admin passwords) in the clear in some file. I think it is almost criminally negligent, but then I am a CISSP. Having said that, there have been many notably lame attempts to encrypt the password in such a way that it was trivial to reverse the encryption making it exactly the same as clear text to anyone with a middlin knowledge of cryptography. Something to keep in mind, though... In almost all modern commercial OS's, any administrator logon has full rights to view any process memory space, registers, files, etc. making it essentially useless to protect yourself from administrators. The bigger worry is that someone gets their hands on a backup tape or, as you suggest, hacks in from the outside and has the same permissions as the server to read the file. If you have a password protected web page (and you care to protect it), you MUST use SSL to protect against eavesdroppers. Of course that won't protect the client from keystroke loggers installed via Trojan horses nor will it protect your server from a hacker that 0wns it. The best thing to do is have a throwaway password for the account so if it does get hacked it doesn't compromise all the rest of your accounts, but then you knew that already.

First, using SSL for the authentication is as simple as using https rather than http for the authentication script - correct? As to my LDAP, that is using TLS - so, all passwords are transmitted encrypted.

I understand that the administrators have access to all of the files and memory, but getting access to the actual typed password requires a level of effort. On a UNIX system, the password is typed into the login process and immediately checked for validity by that process - so, other than a few moments in memory, it hardly exists in plaintext on the box. I am certain that a sysadmin "could" rewrite the getty process or whatever process is doing the authentication, but that takes a certain level of sophistication. In the case of php, the passwords are available in plaintext as Global variables - global to a script to look at. It seems to me that it would be nice to have an encrypted password given to me by php that I could check against. Trouble is, as the passwords are hashes, I suppose this won't work as the server can't decrypt my encrypted password.

I suppose that security types find no difference between protection from a sophisticated or novice user - maybe that is my biggest error - assuming some level of protection by thinking there were "levels" of security - when in reality, you are either secure - or not. But still, the idea of levels of security seems acceptable - and having my passwords availbale in plaintext from an out of the box OS does not.

Yes, SSL is as simple as using HTTPS (though your web server must be set up to handle that).

I don't know anything about PHP, but it has been around long enough that I feel quite sure that the admin level would be using the one-way encrypted password just like *nix and Windows. As for the CGI programs (perhaps that is what you are talking about), that would be up to the programmer. In my web programming (I use C/C++ compiled binaries (occasionally some Perl), not PHP scripts) I only store the one-way hash (I use my own algorithm based on the SHA-1 hash, but I would expect PHP to have something built-in that has been vetted by some security geeks somewhere) in the file for just such concerns. The CGI script/program only has the plain text password for a brief time as it creates the hash, then it compares the hash with that stored. If they match then the password was correct and off to the races. If you are using some sort of web-based administration package, it may store the passwords in the clear (if so, my advise is to switch packages!) and this could be your concern. I generally do all my work via ssh and the command line, but I am quite comfortable working in that environment, others may find the learning curve to be too steep.

The attached script is, from what I can tell, a rather standard php login script. To change the authentication method and avoiding storing the password in the script, one can embed a php-ldap authentication mechanism. All of the ldap stuff is handled via TSL and the authenticate php script is called via https. So, from the network perspective, I feel rather secure. What troubles me is that the PHP_AUTH_PW is the plaintext password that the user types in. As long as my php script uses it to authenticate, and then does nothing else, no big deal. What bothers me however is the relative ease to which anyone with system privileges can edit this file and write out the PHP_AUTH_PW. If the user is using the same password on another system, then they are vulnerable. While I recognize that the user deserves what they get for using the same password on two systems, it seems a shame that it is so simple in php to acquire the plaintext of someones password.

This also seems to say that LDAP cannot be securely shared across two networks as anyone with root privileges on one network can easily access the users password and thus be the user on another network.

Again, I guess this makes sense - it just was shocking that there is no mechanism in place to make the plaintext password more difficult to access.

<?php
function authenticate() {
header('WWW-Authenticate: Basic realm="My Server"');
header('HTTP/1.0 401 Unauthorized');
echo 'Authentication Failed';
exit;
}
if (!isset($_SERVER['PHP_AUTH_USER']) ) {
authenticate();
}
$user = 'username';
$password = 'password';
if($_SERVER['PHP_AUTH_USER'] == $user && $_SERVER['PHP_AUTH_PW'] == $password){
session_start();
$_SESSION['loginID']=$u_name;
$_SESSION['authenticated']=1;
}
else {
authenticate();
}

I can't even pretend to know what you are talking about, the only think I know about PHP is it has 'C like syntax'. If this is a script you can control, you can do something like this (in pseudo code):

Get password from client message (parse cgi, whatever).

One-way encrypt password (I know in Perl that there is access to the unix crypt algorithm, probably good enough for these purposes).

Read previously encrypted password from file (this, of course, means you can't send the user his password if he looses it, you can only reset it to some default value).

Do a comparison to see if the hashes are the same, if so the user is authenticated.


I suspect that PHP either has a one-way password hash algorithm or has the same Perl access to the underlying crypt algorithm, so you shouldn't need to roll your own. Under these circumstances you never store the plain text password, but naturally it could still be hacked by someone with root access (but as you say, it takes a bit more skill than average). I believe that the unix crypt pass also takes a 'salt', so if you pick something random as the salt (it can't change once you picked it) then even if someone had the exact same username and password on another unix system the hash would be completely different.

Of course this advice is meaningless if you can't change the code on your machine.

What I am saying is that PHP has the password stored as plaintext. Yes, it can be encrypted and then checked, it can also be checked with LDAP.

What I am saying is that sysadmin with evil intentions has extremely simple access to the plaintext passwords by simply querying the global variable and then saving the plaintext password - I am talking about a sysadmin doing something that they shouldn't. While I know that the sysadmin already has access to everything of the users on the box, I am not used to them having easy access to the plaintext passwords of the users.

In a command line login, this same sort of activity would require that the evil sysadmin would have to rewite and recompile the login routines.

So, all I am saying is that it appears to be critical that all users use different passwords on different networks. I assume that many of these readers already knew this, but I guess I am a believer now.

I was simply wondering if I was missing some way to protect the users plaintext from causal sysadmins with evil intents.

Again, the concern isn't what the sysadmin could do on the network that they control - it is that users who negligently use the same password on networs A,B, and C are essentially giving access to their accounts to sysadmins who may have access on only one network.

More directly, if I, as a professor, have a student sysadmin on a engineering web server, and I happen to use the same password on another network where I input grades, then I am essentially giving that student sysadmin my password when I use the php web interface. It is exceedingly simple for that student sysadmin to get my plaintext password.

For some reason, it seems to me that this would be a little more difficult using standard console logins - but maybe only a little bit. Maybe I have been deluding myself.

I dont know a thing about programming so I would take the easy route as a evil sysadmin or heck anyone on your LAN and use a program that will use arp poisoning and just suck up all your passwords whether they are encrypted or not and throw them in a cracker ran up against a dictionary attack then brute force them if that does not work.

While that sounds simple, the truth is that a decent password cannot be hacked by a dictionary attack and a brute force attack requires a significant amount of hardware and/or time that are far beyond the abilities of a casual hacker.

And this is basically the crux of what I am saying - I used to believe the unix passwords were somewhat protected as a sysadmin has to hack into the OS and muck with the login stuffs to try and get the plaintext password. With Web authentication in PHP - the plaintext password is readily available. So, even if you have a decent password selected, you had better be using it on one network and one network only.

Unfortunately most people use dictionary words or all alpha characters, in most cases I can break down 80% of a networks user passwords in less than a week having no rights on the network at all myself. if passwords are being sent plain text to your PHP login no cracking is necessary at all, use ssl then have a tacacs+ or RADIUS server actualy hold the passwords so they are not on your *nix box at all. the easiest way is if the sysadmin has rights to the login script you just have a keylogger do a stealth install from the login script ( my only point with this is you have to trust the sysadmin they can get to anything even unknowledged sysadmins would just change the users password and then wait for the user to call in because they cant authenticate giving them full run of the users stuff in the meentime).

Good Sir! Tis just one of the inherent deficiencies of all serverside script which as it relates to the web has existed since the old pearl days ( I remember them well). Your solution is not to use script.