PHP connect to MySQL security

[NeoDreamer]

Can people go into the PHP file that I use to connect to MySQL and see my password?

[JustJeff]

If you mean using FTP or a file editor - Yes - if the file is readable to them (chmod 644, for example), then yes, they can see the MySQL password.

If you mean viewing it over HTTP (through a browser), probably not...

[NeoDreamer]

I don't mean stollen off my computer. I mean viewed on the web.

I noticed that if a folder on your website does not have an index.html or index.php, then some hacker can type in www.site.com/folderWithouIindex and view all the files under that folder. Then they can go into the PHP file with your MySQL connection and peek at your password.

[bwh2]

I don't mean stollen off my computer. I mean viewed on the web.

I noticed that if a folder on your website does not have an index.html or index.php, then some hacker can type in www.site.com/folderWithouIindex and view all the files under that folder. Then they can go into the PHP file with your MySQL connection and peek at your password.
in this instance you should have custom made 404's. you can also shut off the viewing of a directory's files with your index manager.

[Cybernoid]

I don't mean stollen off my computer. I mean viewed on the web.

I noticed that if a folder on your website does not have an index.html or index.php, then some hacker can type in www.site.com/folderWithouIindex (http://www.site.com/folderWithouIindex) and view all the files under that folder. Then they can go into the PHP file with your MySQL connection and peek at your password.

Even if they'd see the directory listing, they couldn't open the PHP-file. Every time a PHP-file is loaded from the server, it's translated, so you won't see the PHP-code. Only way to see the code is by transferring it via FTP or similar.

[aknatn]

I would put blank index files, custom 404's, set CHMOD to 755 and turn off directory listing if I was concerned with security. Oh yeah, and trip wires rigged to shotguns and man eating sharks that fall from the ceiling.

[NeoDreamer]

And don't forget to say "release the hounds!" (Mr. Burns style). :gm:

[teiz77]

if the username and password is not echoed or printed to the browser a 'hacker' can never see the password in a php document. Assuming you put them into a variable.

[JustJeff]

if the username and password is not echoed or printed to the browser a 'hacker' can never see the password in a php document. Assuming you put them into a variable.

I debated whether or not to post this ...

Here's a catch. Every once in a while (hopefully a very long while), webservers are upgraded. During this upgrade, it's common for them to change configurations, and if that configuration forgets to load PHP (for example), then it's possible that someone could (cleverly) request the file with your username/password and get it in plain text.

You may say "What?! That never happens!" - and I can assure you that it can, does, and will happen. The only solution is to keep the user/pass stored in a PHP file OUTSIDE of the web root, so even if the results are returned as plain text rather than interpretted as PHP, the user cannot directly request the configuration file with your user/pass.

[Xeef]

other question

even if somebody woud know my SQL user/password
coud i prewent NONlocal conections to it ?

mean the hacker woud need to place a PHP on the server to have access ?!

[JustJeff]

Yes - you can explicitly list the host/hosts that can access mysql - if you control the user settings for MySQL.

If it's your own server, it's not a problem. If you're hosted, you may have to ask your host to do it (though I know it's the default for many hosting control panels).

Most reputable hosts won't have a problem forcing local connections.

[NeoDreamer]

Does it even matter if someone saw the password for a created user? The hacker couldn't do anything with that password since usage of the database is only granted for whichever domain you choose.

[Xeef]

Hmmm

then SQL is prety save
the hacker need to know the pasword for the DB & for FTP

[foodpk]

Not to mention that you shouldn't store your passwords in raw form but should encrypt them with the md5 algorhytm. Then it's virtually impossible to retreive the password from the md5 hash.

[λ]

What I'd do is make a php file called defines.php which contained something like:



<?php
$username = "me";
$password = "irocktheworld805";
?>

And put that in a folder with access banned using a .htaccess, and then include that in my scripts and use $username and $password instead of having them as plain text (it also means that if you are hacked somehow you can quickly change the username and password to something else :)).

[Xeef]

foodpk

how is this md5 encryption is working ?

so instead of
$password ="ABC"
you have somthing like
$password = "aabfedee0424ae2" ?

but then
if the server grant you access whit this string then it doesn't mather to a hacker does he know "ABC" or "aabfedee0424ae2"
he get access whit both ?

can you give a description on this

THX Xeef

[JustJeff]

You can't md5 encrypt a mysql password.

You can hash passwords that you STORE in a database, but the password used to CONNECT to the database is going to have to be plain text.

[Cybernoid]

foodpk

how is this md5 encryption is working ?


The idea is that you only store MD5-encrypted passwords in your database.

When you ask your user for a password, you MD% hash it when you get it and compare it to the one in the database. If they match, you let the user in. This way you only move the real password once. And if you're using sessions or similar, the hacker won't be able to see the MD5-encrypted password and even if he could he'd need to start a session on the server with the matching user id and MD5-encrypted password, which is really hard.

[Xeef]

ok that i was know

but i was understanding "foodpk" so that you can use something similay in you php to access the DB

but THX for replay

[teiz77]

The idea is that you only store MD5-encrypted passwords in your database.

When you ask your user for a password, you MD% hash it when you get it and compare it to the one in the database. If they match, you let the user in. This way you only move the real password once. And if you're using sessions or similar, the hacker won't be able to see the MD5-encrypted password and even if he could he'd need to start a session on the server with the matching user id and MD5-encrypted password, which is really hard.

you shouldn't store a password in a session.

[Cybernoid]

you shouldn't store a password in a session.

Did I say you had to? And why shouldn't you? The session never leaves the server, it's much safer than sending it back and forth.

[hl]

Did I say you had to? And why shouldn't you? The session never leaves the server, it's much safer than sending it back and forth.
anyone who gets access to the php session id can access another users account if the password is stored

[petefs]

a) store sessions outside of web-accessible directories
b) use an alternate session storage engine, i.e. mysql : ) There are a variety of good scripts out there for session handling in a variety of sql database. that way having access to the session id by itself is of no great import.

[Cybernoid]

anyone who gets access to the php session id can access another users account if the password is stored

If someone gets access to the session, then he already has access to the server. So one password doesn't make a difference.