RE: [PHP] Using encrypted passwords
And the good Lord saw that clear was bad and gave us ssh...
If you care that much build an ssh tunnel to the db server and talk over
that.
-Original Message-
From: Jason Wong [mailto:[EMAIL PROTECTED]
Sent: 20 December 2004 17:29
To: php-general@lists.php.net
Subject: Re: [PHP] Using encrypted passwords
On Tuesday 21 December 2004 00:03, symbulos partners wrote:
is it possible to use encrypted passwords in php files, for connecting
to a database?
We do not like too much the idea of the password being in clear text.
Example
$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
'mysql_password' should be encrypted
Why? It's not going to offer any protection. If I know your encrypted
password and am able to access your database using it there is no reason
for me to know what your cleartext password is. In other words if I am
able to read the file containing your password (whether encrypted or
cleartext) then I can access your database.
This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information visit
http://www.citc.it
___
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using encrypted passwords (what we would like to achieve)
On Tuesday 21 December 2004 20:06, symbulos partners wrote: What we would like to achieve? If a malicious user finds a way of entering of accessing the docroot (rwx) of a website with CMS (PHP + MySQL), we would like to have further barrier to him accessing the Mysql database. Like I said, you're storing the means to decrypt on the same system, so once someone gets in no amount of encryption will help. So basically encryption (for this purpose) is a waste of time and adds no value. Your best defence is to prevent them from getting in in the first place. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* It's raisins that make Post Raisin Bran so raisiny ... */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using encrypted passwords (what we would like to achieve)
symbulos partners wrote: What we would like to achieve? If a malicious user finds a way of entering of accessing the docroot (rwx) of a website with CMS (PHP + MySQL), we would like to have further barrier to him accessing the Mysql database. We had some problem with one hacker using the database of a website with PhpBB launching an e-mail based DDoS (this is what they said at the provider hosting our server). We are trying to introduce as as many obstacles as possible. Excellent! Encoding the password in that config file won't help you meet your goal in the least. If they can read it, they can read it, and they are reading the same thing PHP uses to access the database, so they can access the database. You can't make it something they can't use to access the database, but that PHP *can* use to access the database. Making it difficult for somebody to physically *read* that password will help, however. Alas, you can't make it *too* difficult, or PHP also can't read it, and then your site has no database access at all. Standard procedures include: Moving config files with passwords out of Apache's DocumentRoot and using PHP's include_path setting to make them readable by PHP. Some people recommend making the .inc and files be parsed by PHP or not served up by Apache by tweaking Apache settings, or tacking .php onto the end of all .inc files. The problem there is that you *still* have files that the Programmer never intended to be accessed as a web page, available for hackers to access as a web page. IE, they can surf directly to http://example.com/someBB.config.inc.php and they are executing PHP code in a context never really designed, considered, and certainly not tested by the majority of Programmers out there whose code you acquire. So, despite strong opposition on this list, I must continue to advise you to *MOVE* any PHP/.inc file that is not an actual page people are supposed to surf to, *out* of DocumentRoot, and use include_path to make PHP find them. But the goal here is to make it IMPOSSIBLE for the General Public to *surf* to your config.inc.php script, and read the password, or otherwise abuse the PHP source code within it to cause mayhem. You've narrowed your potential attackers down from The Planet (billions of users) to Shell Users (hundreds++, at most). That's a Big Difference, imho. Now, anybody with a shell account (or who breaks into a shell account) can still use PHP to read your PHP config.inc.php script, and still get ahold of the password -- Or run that PHP script out of context to cause problems. Your options for guarding against that include: +++ Traditional Answer: Guard shell access very carefully. Downside: Not real practical in a shared-host environment, with hundred++ users. Upside: You should be doing this anyway on a dedicated server, so the risk is minimal. In fact, if a user you don't want to have shell, has shell, then they MySQL password is probably *not* your most critical problem at that point. Way too many nasty things they can do with a shell account that supersede your MySQL password access. +++ Low-volume Server Possibility w/ Apache 1.x: Use PHP as a CGI, and suexec PHP-CGI to a specific user, and make the config.inc.php file readable only by that specific user. Downsides: suexec is a pain to get right, and if you get it wrong, you open up way more security holes than the MySQL passwword problem in the first place. CGI is slower than Module, and is missing a few (four?) features. CGI *might* not be *that* much slower if all your PHP scripts and PHP and Apache children can fit into RAM. It *might* also not really matter if CGI is slower for a low-volume server -- Only you can make the performance/security decision for your needs. MOST people seem to opt for PHP as Module performance over the security risks of a compromised shell account. But, hey, it's your server. You make the choice. One feature I can recall that CGI won't support: HTTP Authentication, as it would transmit HTTP password in the clear between processes (Apache and PHP CGI). If you NEED HTTP Authentication (in PHP, not in .htaccess or mod_auth_mysql or whatever) then you don't want PHP as CGI. There are a few other features, mostly minor features that I never wanted anyway, as I recall... You can probably read up on PHP CGI page to find the other features you'll be missing. +++ With Apache 2.x, I've been told that you can run PHP Module as a specific user, independent of the Apache user, for each site. This means that in a shared host environment, every host can run PHP as a Module under a *different* under-powered shell user, with only that ONE user able to read the PHP files. This protects your MySQL password from all other users on the system, which is not possible in 1.x, as I understand it, on shared servers using VirtualHost. One could run a different Apache 1.x process for each user, of course, but that's problematic from a limited resources
Re: [PHP] Using encrypted passwords
On Tuesday 21 December 2004 00:03, symbulos partners wrote:
is it possible to use encrypted passwords in php files, for connecting to a
database?
We do not like too much the idea of the password being in clear text.
Example
$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
'mysql_password' should be encrypted
Why? It's not going to offer any protection. If I know your encrypted password
and am able to access your database using it there is no reason for me to
know what your cleartext password is. In other words if I am able to read the
file containing your password (whether encrypted or cleartext) then I can
access your database.
--
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems Integrators
* Web Design Hosting * Internet Intranet Applications Development *
--
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
--
/*
APL is a write-only language. I can write programs in APL, but I can't
read any of them.
-- Roy Keir
*/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using encrypted passwords
Jason Wong wrote: Why? It's not going to offer any protection. If I know your encrypted password and am able to access your database using it there is no reason for me to know what your cleartext password is. In other words if I am able to read the file containing your password (whether encrypted or cleartext) then I can access your database. Sorry for the silly question, you are probably right. Would it be possible to encrypt the whole file, so that the password could not be read? -- symbulos partners -.- symbulos - ethical services for your organisation http://www.symbulos.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using encrypted passwords
symbulos partners wrote:
Dear friends,
is it possible to use encrypted passwords in php files, for connecting to
a
database?
We do not like too much the idea of the password being in clear text.
Example
$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
'mysql_password' should be encrypted
What do you think you gain by having the password encrypted there?
Please take us, step by step, through the algorithm by which this stops a
Bad Guy.
Because, basically, it would *NOT* do any good at all to encrypt it there.
In other words:
If the PHP script can 'read' that password to connect, and the Bad Guy can
read that password to connect, then what format that password is in is
irrelevent.
Whether your password looks like 'password' or
'DEE834KRMF88733JJFDYF6DE6WEY34FJVUEY7347' I can still copy and paste it
into my PHP script or command line and connect to MySQL, once I get to
that point.
If it bothers you that the password is there, then you need to make damn
sure the Bad Guys can't *read* that password.
If you can't reassure yourself of that, consider some other authentication
method or some other method of storing the password that you can protect.
Encrypting a string is not a magic bullet that makes it Secure
You're not looking at the Big Picture of how you can be attacked -- or at
least not understanding how this piece of the puzzle fits in, or you would
already know that encrypting the string here won't do anything useful.
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using encrypted passwords
Symbulos Partners wrote: Jason Wong wrote: Why? It's not going to offer any protection. If I know your encrypted password and am able to access your database using it there is no reason for me to know what your cleartext password is. In other words if I am able to read the file containing your password (whether encrypted or cleartext) then I can access your database. Sorry for the silly question, you are probably right. Would it be possible to encrypt the whole file, so that the password could not be read? Somewhere on your web server you are going to need to have whatever information is necessary for the web server to decrypt the file so that it can make use of it. That information will need to be readable by the user your web server is running as, just like your current file. About the only security benefit I can see from something like this is if the information required to decrypt the file came from the web site user over an SSL encrypted session, otherwise you are simply moving your plain text information to a different file. - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Using encrypted passwords
What you might want to try doing is to create a connect.php file that exists outside of your doc root that has the variables with your information and simply include this file when you need to connect to your DB. Now, this won't change the root problem - if someone's able to snoop your transmission then they can pull the info you're sending from the web server to the SQL server... But you'll run into this unless *the communication* between the two machines are encrpyted. This means that having specific files be encrpyted or not is somewhat pointless in this situation. -M Sorry for the silly question, you are probably right. Would it be possible to encrypt the whole file, so that the password could not be read? -- symbulos partners -.- symbulos - ethical services for your organisation http://www.symbulos.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using encrypted passwords
On Tuesday 21 December 2004 02:15, symbulos partners wrote: Sorry for the silly question, you are probably right. Perhaps it would be better if you say what you are trying to achieve. Would it be possible to encrypt the whole file, so that the password could not be read? Encryption is only useful for data that is in transit or in storage. If the data is in use then it needs to be decrypted. If you're storing (or have) the means of decryption on the same system as where the encrypted data resides and someone malicious was able to get into your system they would have the encrypted data and also the means to decrypt it. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* We ought to make the pie higher. George W. Bush February 15, 2000 Comment made in Columbia, South Carolina during presidential campaign. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
