|
|
Posted by Jerry Stuckle on 05/28/07 03:04
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
==================
Navigation:
[Reply to this message]
|