hallo,
I use PHP and I'd like to not write in hardcoded way password
and login to access to mysql.
how to not write password in code for access to mysql?
How can I do?
I'd like that who see my code don't see my paswords.
there is a solution?
Thank you in advance.
Mario.

_mario.lat wrote:
> I use PHP and I'd like to not write in hardcoded way password
> and login to access to mysql.
> how to not write password in code for access to mysql?
> How can I do?
> I'd like that who see my code don't see my paswords.
> there is a solution?

I assume you use a Unix like system for your server.

I assume you have your PHP scripts in ~/public_html

Then you can create a directory ~/mypasswords

Now you can create the following file

--- ~/mypasswords/mysql.log.data.php ---
<?PHP
$mysql_login="loginname";
$mysql_passw="secretpass";
$mysql_host="localhost";
$mysql_database="mydb";
?>
-- eof ---

Now in your php script that users can surf to

--- ~/public_html/index.php ---
<?PHP
require_once('../mypasswords/mysql.log.data.php');
mysql_connect($mysql_host, $mysql_login, $mysql_passw);
mysql_select_db($mysql_database);

//and so on...
?>
--- eof ---

Even if there would be a misconfiguration, and the PHP engine would be
disabled, and the code is displayed in raw, no one will be able to see the
login/password/host/database in your code, just see to that the user who is
running the web server has the privileges to read the
~/mypasswords/mysql.log.data.php, but don't make the directory publicly
available on the net (no symlinks to the file or directory in your ~/public_html).

--

//Aho

Ya that was fine what J.O told but rather than creating that file in
public_html crate a .conf file in /etc. for the first installation
take the username and password from user and store it in /etc/
proj_name.conf file and in db.connect.php parse it..

Ravi wrote:
> Ya that was fine what J.O told but rather than creating that file in
> public_html crate a .conf file in /etc. for the first installation
> take the username and password from user and store it in /etc/
> proj_name.conf file and in db.connect.php parse it..
>

Read it again. J.O. did not say to create the file in public_html.

And most hosting companies do not allow you to write to /etc. You need
a vps or dedicated server to be able to have write access to that directory.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

>> I use PHP and I'd like to not write in hardcoded way password
>> and login to access to mysql.
>> how to not write password in code for access to mysql?
>> How can I do?
>> I'd like that who see my code don't see my paswords.
>> there is a solution?
>
> Now you can create the following file

Thank you for answering me.
I'm shure there is a better way with cript:
DES or SHA, RSA...
Mario.

_mario.lat kirjoitti:
>>> I use PHP and I'd like to not write in hardcoded way password
>>> and login to access to mysql.
>>> how to not write password in code for access to mysql?
>>> How can I do?
>>> I'd like that who see my code don't see my paswords.
>>> there is a solution?
>> Now you can create the following file
>
> Thank you for answering me.
> I'm shure there is a better way with cript:
> DES or SHA, RSA...

Good luck reversing your database password from a one-way hash.

--
Rami.Elomaa@gmail.com

"Wikipedia on vähän niinq internetin raamattu, kukaan ei pohjimmiltaan
usko siihen ja kukaan ei tiedä mikä pitää paikkansa." -- z00ze

_mario.lat wrote:
>>> I use PHP and I'd like to not write in hardcoded way password
>>> and login to access to mysql.
>>> how to not write password in code for access to mysql?
>>> How can I do?
>>> I'd like that who see my code don't see my paswords.
>>> there is a solution?
>> Now you can create the following file
>
> Thank you for answering me.
> I'm shure there is a better way with cript:
> DES or SHA, RSA...

As Elomaa already pointed out, you will have big trouble to decrypt the one
way hashes. You could use rot13 to encode/decode your passwords, it's not much
protection, but at the first glance someone may think it's the plain password,
to the point when they check your script that decodes the password, at which
point they will see the rot13, but that applies all two way encryption, as you
need the decoder in your php script, they will be able to decode your encoded
password without any trouble.

When you use an Unix like system, you can change the password files privileges
and that way protect the password from other persons eyes.

Assuming that your user names is mario and that the apache server is run as
the user apache, then do a "chown mario:apache -R ~/mypasswords" and then
"chmod o-rwd -R ~/mypasswords"

This way only you and the web server can read the file with your password, no
other user except root will be able to read the file.

--

//Aho

On 27 May, 17:56, "_mario.lat" <n...@libero.it> wrote:
> >> I use PHP and I'd like to not write in hardcoded way password
> >> and login to access to mysql.
> >> how to not write password in code for access to mysql?
> >> How can I do?
> >> I'd like that who see my code don't see my paswords.
> >> there is a solution?
>
> > Now you can create the following file
>
> Thank you for answering me.
> I'm shure there is a better way with cript:
> DES or SHA, RSA...
> Mario.


IF you use a reversible encryption then the problem still remains that
a password needs to be kept somewhere PHP can read it.

One place to keep the password off the server is at the client end -
and you could have have one database password stored encrypted using
each users password. But you then have the problem of getting the
users password sent securely to the application (not to mention non-
authenticated access).

Jerry Stuckle rightly said:
> And most hosting companies do not allow you to write to /etc.

But most do block HTTP access to files beginning with .ht - but these
can be read locally.

So if you can't work with files outside your web root, you can get the
same effect by putting your password in .htppasswd.inc.php and
including that. Although honestly it's not a big gain over including a
php file which is directly addressable and parsed as a php file.

At the end of the day there's no simple solution to ensuring that only
your approved scripts read from your configuration files to get
credentials to access other secure resources. base_open_dir goes a
long way to improving things on a shared server if its done right -
but it doesn't provide any protection if a malicious user can get
their own php code executing on your server.

Suhosin has a lot of interesting bits in in it - like a session
encryptor, but I think that there is potentially a gap in the
marketplace for a trusted php platform.

C.

On Sun, 27 May 2007 18:56:11 +0200, in alt.php "_mario.lat"
<none@libero.it>
<pan.2007.05.27.16.56.08.951551@libero.it> wrote:

>| >> I use PHP and I'd like to not write in hardcoded way password
>| >> and login to access to mysql.
>| >> how to not write password in code for access to mysql?
>| >> How can I do?
>| >> I'd like that who see my code don't see my paswords.
>| >> there is a solution?
>| >
>| > Now you can create the following file
>|
>| Thank you for answering me.
>| I'm shure there is a better way with cript:
>| DES or SHA, RSA...
>| Mario.

Something that hasn't been discussed is mySQL views.
If you are running mySQL 5+ then you can create a view.
---------------------------------------------------------------
jnorthau@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------

C. wrote:
> On 27 May, 17:56, "_mario.lat" <n...@libero.it> wrote:
>>>> I use PHP and I'd like to not write in hardcoded way password
>>>> and login to access to mysql.
>>>> how to not write password in code for access to mysql?
>>>> How can I do?
>>>> I'd like that who see my code don't see my paswords.
>>>> there is a solution?
>>> Now you can create the following file
>> Thank you for answering me.
>> I'm shure there is a better way with cript:
>> DES or SHA, RSA...
>> Mario.
>
>
> IF you use a reversible encryption then the problem still remains that
> a password needs to be kept somewhere PHP can read it.
>
> One place to keep the password off the server is at the client end -
> and you could have have one database password stored encrypted using
> each users password. But you then have the problem of getting the
> users password sent securely to the application (not to mention non-
> authenticated access).
>
> Jerry Stuckle rightly said:
>> And most hosting companies do not allow you to write to /etc.
>
> But most do block HTTP access to files beginning with .ht - but these
> can be read locally.
>

They block http access to files beginning with .ht only if your
httpd.conf and/or .htaccess stop this access. With neither of the
above, the files can be access.

> So if you can't work with files outside your web root, you can get the
> same effect by putting your password in .htppasswd.inc.php and
> including that. Although honestly it's not a big gain over including a
> php file which is directly addressable and parsed as a php file.
>

Most shared hosts give you access to a directory one level below your
web root. The best place to put the files are in a directory (other
than your web root) off of here. They will still be accessible via PHP,
but not from the web.

> At the end of the day there's no simple solution to ensuring that only
> your approved scripts read from your configuration files to get
> credentials to access other secure resources. base_open_dir goes a
> long way to improving things on a shared server if its done right -
> but it doesn't provide any protection if a malicious user can get
> their own php code executing on your server.
>

Nothing works if a malicious user gets his php (or any other language)
code running on your server. But with proper security, even a shared
host can prevent others on the same host from executing code in your
area. At that point the most common problem is caused by insecure
userid's/passwords used to upload files, access admin areas, etc.

> Suhosin has a lot of interesting bits in in it - like a session
> encryptor, but I think that there is potentially a gap in the
> marketplace for a trusted php platform.
>
> C.
>


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================