Jump to content

Getting a password securely


jhsachs

Recommended Posts

I understand that the commonly used means of securely supplying a password to a script is to store it in a text file outside the document directory. The script reads the file and extracts the password. Because the password is stored outside the document directory, it is difficult for an intruder to steal.

 

This makes sense, but it seems more complicated than necessary. Why not assign the password to a variable in an include file stored outside the document directory? The script can simply include the file instead of having to open a file, read it, and parse it. The security is the same.

 

I've tried this technique on my development system (WAMP) and on my client's hosted test site (LAMP), and it works in both places. (In each case the directory I chose was the parent of the document root. In Windows it is the root directory of my data disk. In Linux it is a child of the account's home directory.)

 

Am I just lucky that this is working for me? I'm puzzled that it isn't used in preference to the read-a-file technique.

Link to comment
Share on other sites

I'm puzzled that it isn't used in preference to the read-a-file technique.

I've only ever seen this technique used with Mani Admin Plugin or Source Mod on Source game servers.

 

If you're talking about PHP, then you don't even have to go to the trouble of placing the file outside the root directory.

 

This is an acceptable use:

 

public_html/password.php:

<?php
  $my_password = "password";
?>

 

public_html/myscript.php:

<?php
  require_once("password.php");
  echo $my_password;
?>

Link to comment
Share on other sites

I'm sorry MasterACE14, I don't follow what the code is doing. It appears to me that myscript.php is simply getting the password by including another script from the same directory. That's hardly more secure than putting the password directly in myscript.php; the only additional work an intruder has to do to steal the password is look at a second script.

Link to comment
Share on other sites

Php code in a .php file cannot be seen outside of the actual file on the server. HTTP requests for the file only result in any output from that file. Unless you echo your password in your php code or php no longer works, it is safe to put passwords in a .php file as php code. Making a HTTP request for the file simply wastes server resources serving up a .php file that doesn't output anything.

 

If you do put your included files inside the document root folder (i.e. for server setups where you cannot put files outside of the document root folder), you typically put all of them into a common folder and then use a .htaccess file to prevent all HTTP requests for the files in that folder.

Link to comment
Share on other sites

PFMaBiSmAd, I don't think you (or MasterACE14) understood what I'm trying to do. The point is not to assure that the passwords will be secure as long as everything is working as it should. The point is to improve the odds that the passwords will remain secure when something is not working as it should... for example, when an intruder gets unauthorized access to the document root, as happened on my client's hosted site a few weeks ago.

 

For context, I googled "php database password security." The first four matches all mentioned the technique I described (see below). Some suggested storing credentials in the inaccessible file as code, others as data. I found nothing that pointed authoritatively to one technique or the other being more reliable and/or secure.

 

Using .htaccess to block access to a file that is in the document space was also mentioned in several places. That is certainly easier, but again, I've found nothing to help me judge whether it is equally secure, less so, or more so.

 

That is what I'm asking about.

 

Here are the four references I mentioned above:

 

http://php.net/manual/en/function.mysql-connect.php: "I recommend creating connect and cleanup functions in a separate include file.  If security is a concern, locate the include file outside of your web root folder."

 

http://www.sitepoint.com/php-security-blunders: "Place configuration files outside your Web-accessible directory. A configuration file can contain database passwords and other information that could be used by malicious users to penetrate or deface your site; never allow these files to be accessed by remote users."

 

http://stackoverflow.com/questions/97984/how-to-secure-database-passwords-in-php: "If you're hosting on someone else's server and don't have access outside your webroot, you can always put your password and/or database connection in a file and then lock the file using a .htaccess..."

 

http://phpsec.org/projects/guide/3.html: "Of course, one simple solution is to place all modules outside of document root, and this is a good practice. Both include and require can accept a filesystem path, so there's no need to make modules accessible via URL. It is an unnecessary risk."

Link to comment
Share on other sites

Like PHMaBiSmAd said, if someone is able to access the files on your server, most likely over FTP. Then you should change your FTP password. As far as people working out a password stored in a variable in a PHP script goes... it simply doesn't happen and you're greatly over thinking it.

Link to comment
Share on other sites

I'm trying to write this in a diplomatic way, but the message makes that difficult. Please bear in mind that no offense is intended.

 

You can't answer my question because you don't understand the basic principles of security, in particular, the concepts of mitigation and layering.

 

I'm writing this because you can get in a lot of trouble if you try to work on a web site that has security issues and you don't understand them -- or don't at least understand that you don't understand them. I don't want you to get in trouble, at least not because I took the easy way out and walked away from this thread.

 

I'd encourage you to get a basic understanding of this topic. The PHP Security Consortium, http://phpsec.org, is probably a good place to start. The most important information is not PHP specific, though, and may be best found elsewhere. I'm sorry I don't have a set of references handy. If there's interest, I'll make a point of finding some.

Link to comment
Share on other sites

I'm trying to write this in a diplomatic way, but the message makes that difficult. Please bear in mind that no offense is intended.

 

You can't answer my question because you don't understand the basic principles of security, in particular, the concepts of mitigation and layering.

 

I'm writing this because you can get in a lot of trouble if you try to work on a web site that has security issues and you don't understand them -- or don't at least understand that you don't understand them. I don't want you to get in trouble, at least not because I took the easy way out and walked away from this thread.

 

I'd encourage you to get a basic understanding of this topic. The PHP Security Consortium, http://phpsec.org, is probably a good place to start. The most important information is not PHP specific, though, and may be best found elsewhere. I'm sorry I don't have a set of references handy. If there's interest, I'll make a point of finding some.

 

This entire post is hilarious.

 

If your server is compromised, your data is compromised.  You cannot assume that only your document root will be victimized.

 

PFMaBiSmAd said everything necessary in Reply #3.

 

And, really, there's no functional difference between keeping a password in a plaintext file and using PHP's file access methods to access it, or storing it as a variable and include-ing it.  What matters is that the password is either placed outside of the web root, if possible, or protected by an .htaccess file if not.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.