How inherently secure is PHP and MySQL?
If I were to set up a database and a small form asking for personal information, how hard would it be for someone to hack it and get into the database full of personal information?
At what level should security features be most important? HTML, PHP, MySQL?

------------------
To artificial life, all reality is virtual.
HTP

http://www.php.net/manual/en/security.index.php

That might help.

Thanks.
I have a problem (like a lot of us), and that is I don't check the manual first. Heh...

But what are your suggestions/experiences with security?

------------------
To artificial life, all reality is virtual.
HTP

As long as you code your backend right, noone wil ever get in that way. Just make sure your server is as secure as you can get it. (IE, shut off all unnecessary deamons, services, etc)

------------------
The future is here, and all bets are off.

Depending on the situation, it might be a good idea to encrpyt the information in your database somehow so that even if someone manages to get into it, they still cant get at anything worthwhile.

------------------
And everything under the sun is in tune, but the sun is eclipsed by the moon...

DSettahr's Homepage

Looks like I have to do some reading.
Heh...


------------------
To artificial life, all reality is virtual.
HTP

MYSQL comes by default with pretty much no security, so keep that in mind if you're setting up a mysql server. Otherwise, pretty much anyone can log in.

------------------
Ω of 14

Well, most situations you will encounter will have the MySQL server running on the same computer as PHP and Apache/IIS; in such a case, a properly-configured MySQL server will not accept connections from other computers, only ones from localhost.

If that is the case, your main concern for security is your own PHP programming--your level of security will depend mostly on how securely your PHP scripts are constructed. That, of course, assumes that you can trust the people that run the server, and that man-in-the-middle attacks are not being used.

There are other concerns, such as filesystem security on the server (preventing other users from accessing files in your directories and gaining your MySQL login or altering your PHP scripts), and the specific MySQL permissions, but those are probably out of your control unless you run the server.

As you can see, it's not a simple topic. But as far as security within PHP scripts, it basically comes down to integrity of external data, i.e. checking all data entered in HTML form fields and query strings. That, and properly-escaped SQL queries.

[This message has been edited by blujay (edited March 08, 2004).]

Well, I want to have 3 databases and 3 different servers in different locations comunicating with each other.


------------------
To artificial life, all reality is virtual.
HTP

Wow. Ok, first of all, I don't really know you, but judging by your posts so far, I'd have to suggest that you may be getting in way too deep here. For someone that is just learning about PHP and MySQL, doing a 3-server setup is, IMHO, a bit much. I've never done it myself, so I can't claim any expertise in it, but I know it's far more complex.

Second, why do you need such a complicated setup? Even Massassi runs on, basically, one server. I can't think of a reason you'd need three servers in three places for a simple form and database. The Internet lets you access any server from anywhere, so one should do the job, it seems to me.

I want one clients database to verify if another clients database has the same user and password.
The user will be common to both clients and they will both have to verify that.
The third database will have the users info and more and will be on another server so that both clients will know the user is my customer.

This is deep and I am a newb. But I am just fiddling with the PHP and MySQL right now. Something I am trying.
I find it's a good way to learn for me.
I have 'borrowed' a database from a friend and I have access to 2 of my own so...

Security is secondary at the moment but will be critical if it all works out.


------------------
To artificial life, all reality is virtual.
HTP

Just setup multiple DB sessions in the PHP script...


If this was Perl, I could show you how to do it . . give you pointers, etc. Too bad your using PHP.

------------------
The future is here, and all bets are off.

Too bad you're using Perl.


------------------
To artificial life, all reality is virtual.
HTP

Well, I still don't understand what you're trying to do, but from what I can tell, it doesn't really sound like you need three servers and three databases to do it.

A few words of advice: Don't make security secondary or worse. If you do that, you'll be doing like Microsoft, and you know all the security problems they've had.

You dont need 3 databases for what you're doing. Just use multiple tables in one database.

------------------
And everything under the sun is in tune, but the sun is eclipsed by the moon...

DSettahr's Homepage

Encrypting info in the db is silly, because if they crack your server enough to get to your db, they will already have access to the information they need to decrypt the info.

Regarding multiple servers: you really need to rethink your design. Why would you have user information stored in three separate places? That completely defeats the purpose of a database as a single place to store your data.

If you think it's more secure to authenticate off multiple servers, think about this: now, you have 3 places to try to keep hackers out of instead of just 1!

So far you've got three experienced programmers telling you that you're being silly. Will you listen?



------------------
EvilMagic.net: Brian's Web Log

No. I know blujay.
I just want to get a script working first. Then I'll re-write the whole thing implementing security.
Of course it would take a long time, but that's the way I learn. :/ And I'm in no rush to get it done.

Each client will have thier own list in a database of users on thier own server for thier records. They will verify that they both have the same user and password.
Then they will both check my database to verify that the user is my customer and get more info on that customer.

Brian, if it won't work, that's ok. I'll try or do something else.
------------------
To artificial life, all reality is virtual.
HTP

[This message has been edited by Darth Evad (edited March 08, 2004).]

I'm not saying it won't WORK

------------------
EvilMagic.net: Brian's Web Log

OK.
Let me try to make this more clear.

Lets say I want to set up a rewards program for Ebay and Amazon customers.
They will both have a database for Evad's Rewards customers. That database will contain users and thier passwords.
So when an Ebay customer buys something and they enter thier Evad's Rewards ID, Ebay will check with Amazon to see if they also have a user and password that matches, and then they will both check with my rewards database to get info and updates (if needed).

Does that make any more sense or explain why I want 3 databases on 3 different servers?


------------------
To artificial life, all reality is virtual.
HTP

Um...sort of...not really...

Why don't you just tell us what you're trying to do? Unless you really are setting up something for eBay and Amazon...

LOL!
Without telling you why I want to do this, the one I conveyed above is the exact same scenario that I would like to have happen.
Both of the clients have thier own servers and databases. I want them to talk to each other and I want them both to talk to me.

It's like one of those phone calls to TechTV.
"I want to change all my video's to .mov so I can trade them with my friend who has QT."
When it really means, "My parents are too stupid to know I installed QT and that's how I watch my pr0n."
Then he doesn't get the answer he is looking for.

------------------
To artificial life, all reality is virtual.
HTP

You should set up a SOAP or XML/RPC server and you can just send simple requests to your various servers so you don't have to go about connecting to multiple databases. Then a script on each machine would handle the details. The advantages to this approach are many:

1. No plain-text db passwords to and from remote servers.
2. Each server can authenticate off any db/table/etc. independently - one server can have a mysqldb and the other can have plain text files or a postgres server.
3. Simplified interface that's separate from where the data is actually stored.
4. Easy to use in other scenerios since you're just processing a request ("Is this user/pass valid on YOUR site?") returns true or false.

------------------
EvilMagic.net: Brian's Web Log