Well... first off, racing_fire, no, PHP DOES NOT support that.

As far as security... I would tend to think that MySQL might be more secure... GENERALLY, PHP runs as the 'nobody' or 'apache' or 'www' user, which is a very unprivildged user, SO the .inc files you write to may need to be read / writable by EVERYONE so that the 'nobody' user can write to them. I'd be cautious of that, since then anyone with access to the server ( ie someone with another account by the same hosting company ) may be able to see that data.

MySQL, on the other hand, requires a username and password to get at your data.

Also, a clarification on SSL... SSL is ( someone please correct me if I'm speaking out of my arse here... ) an encryption method used when data is transfered between server and client, thus WHILE STORED ON THE SERVER, THE FILES ARE NOT PROTECTED BY SSL!

So, SSL is not giving you any more security with using include() than with using MySQL, because none of the data is encrypted until its sent to the client ( ie after all the include() or mysql_query() stuff is done and PHP is finished doing its thing )

But in ANY CASE, if you're worried about storing sensitive data, THEN ENCRYPT IT. NO MATTER HOW YOU STORE IT, FLATFILE, MYSQL, POSTGRESQL, MSSQL, TXT, XML, ETC. IF ITS SENSITIVE ENOUGH TO WORRY ABOUT, THEN FRICKING ENCRYPT IT!

Address I personally wouldn't say are that sensitive... CC#s or SS#s or something though...

    Yeah,

    I'd also say mySQL, or any other SQL server would be your best bet. Other than that, use flat file databases. Encrypt them if there is going to be real sensitive information in them (or at least encrypt the sensitive parts).

    And SSL won't encrypt and protect your file databases on the server file system. SSL is just a layer, used over HTTP connections, to encrypt and protect data that is BEING TRANSFERED. That's all it does.

    And one thing....

    Originally posted by Davidc316

    Basically, I am aware that it would be easier to store all the stuff on MySQL (as opposed to lots of include files), however, I have also read that MySQL is not the ideal place for storing mega sensitive data.

    If these member files were to contain very sensitive data (such as addresses or something), then my thinking is that it would be safer to store that info on some include files which are located on a secure server (which uses SSL).

    mySQL is GREAT for this, although addresses aren't that sensitive you can still encrypt them. You are much safer encrypting them/storing them on mySQL than encrypting them/storing them on the server file system. And as I said up there, SSL D O E S N O T protect data on the file system.

    If I were you, I would DEFIANTLY use mySQL.

      Any SQL database is going to be another layer for someone to crack. You can encrypt your data, or more easily break it into chunks. You can give your tables mysterious names.

      Thus
      Joe Blow
      123 Any St
      Whoville, Wisconsin 34959

      Could be broken into several tables:

      table: MysterioustableONE
      ID / dataelement
      1 / Joe

      table:MysterioustableTWO
      ID/ dataelement
      1/ Blow

      etc.

      You could then do joins:

      SELECT CONCAT (MysterioustableONE.dataelement, ' ', MysterioustableTWO.dataelement) FROM
      MysterioustableONE, MysterioustableTWO
      WHERE MysterioustableONE.id= MysterioustableTWO.id
      AND MysterioustableONE.id=1

      Would return 'Joe Blow'

      Pretty dopey for names and addresses which you can probably already buy by the basketful, but if you wanted to breakup something like credit card data, you could make it tough to crack, or at least so irritating that a hacker would look for easier pickngs elsewhere.

        Thanks for the replies. This has been a very educational thread for me so far!

        Can I just ask one last thing...

        One or two of you are talking about how MySQL would be a much better method. Now, whilst I'm in no doubt that it would be a much easier method, I have read from several sources that MySQL is NOT a mega secure environment in which to store sensitive data. Infact, I have a few PHP books right here with me and all three of them make a point of stressing that you should not store credit card details and such like on MySQL!

        I notice a few of you have suggested encrypting the MySQL data. This is a process that I've never heard of. Could one of you please give me a link or something so that I can learn a little bit more about how MySQL encryption works?

        PS- I read the "Joe Blow" example with interest, but I'm not sure if that would qualify as being secure.

          For encryption; the fact that the encrypted data is being stored in MySQL is irrelevant. Just use whatever encryption you decide to go with, encrypt the data before it goes into the database, and decrypt it when you get it back out (PHP's mcrypt support is as good a place to start as any).

          One thing to note about storing files in a database is that you'll be reading them out into strings, so if you want to store PHP code in them as well, you'd probably want to eval() the string containing each "file".

            Ok Weed, but let me must clarify something... once the info is stored on the MySQL database there would be no encryption at all. Right?

            And if that's the case, then surely it presents a security problem.

            Whether or not we happen to encrypt our data as it makes its way to the MySQL database is irrelevant. The big fear here, remember, is that someone hacks into MySQL and can view all of the MySQL tables.

            Have I got that right?

              A small correction, superwormy. SSL is normally used for encrypting connections between client and server (which can be useful to stop sniffers, etc). But it also can provide a "secure" authentication. In my experience, however, SSL system (especially on Unix), is rather buggy and unreliable. The SSL authentication needs a special user on the server, so anyone who breaks it, can log on as that user,...

              In any case, the suggestion by weedpacket seems to be the best for me. MySQL can be unsafe, but I wouldn't worry about that if I were you. If you use the encryption as suggested, it shouldn't be a big problem. And once you put it in a database, the most databases provide severe security (encryption). Storing credit card info is ALWAYS dangerous (eg privacy laws, hacker security,...). If you want to set up some kind of e-commerce thingy, you need LOTS more security, but if not, you can just forget storing the credit card numbers on your site (since you won't need them).

                David - if you encrypt the data on its way into the database then even if someone hacks into your MySql databse they would see things like

                FHJKL:MNJHD%&%HJDNDB

                And if you decrypted out onto your page that could be

                Dave

                So even if they hacked in it would not make any sens unless they had your key.

                  Originally posted by Davidc316
                  Ok Weed, but let me must clarify something... once the info is stored on the MySQL database there would be no encryption at all. Right?

                  And if that's the case, then surely it presents a security problem.

                  Whether or not we happen to encrypt our data as it makes its way to the MySQL database is irrelevant. The big fear here, remember, is that someone hacks into MySQL and can view all of the MySQL tables.

                  Have I got that right?

                  There are a few places to encrypt you can talk about here.

                  One is to encrypt the data that is sent via HTTP from User-Agent to Apache webserver. For that, you use SSL.

                  Another is to encrypt the data when its being transported to MySQL, for that you need to look at using teh compressed protocal for transfer between MySQL client and server, or SSH tunneling it.

                  Then theres encrypting the actual finally stored data. Both MySQL and PHP have functions that can encrypt the data and store it this way, then you unencrpt it when you pull it back out.

                    Super- I have every respect for you, but I am a bit perplexed at how non of the PHP books I own seem to mention anything about built in encryption functions for PHP or MySQL.

                    I've had a look at the links that you recommended, but the online manuals make for some very heavy reading and I'm gonna have to spend some more time reading and trying to make sense of what it's saying.

                    I know that you're probably thinking "I know for a FACT that PHP and MySQL both have built in encryption functions" and you're probably 100% right.

                    But if they do indeed have built in functions for encrypting credit card details and so on, then I don't understand how there can be so many companies out there selling PHP encryption software to guys like me. Are the producers of these software packages working on the hope that nobody finds out about the built in encryption functions that come with PHP and MySQL???

                      You misunderstand what they're selling. Codelock and similar products ( Zend Encoder ) encrypt your actual PHP scripts, your code, BUT they DO NOT encrypt the data you store anywhere.

                      Those products goal is to ensure that the code you've written can be safely distributed to others WITHOUT the others being able to see your code and how you've done things.

                      What you need is encryption that encrypts the data your scripts store, not the scripts themselves.

                      Go read some tutorials on encryption:
                      http://hotwired.lycos.com/webmonkey/programming/php/tutorials/tutorial1.html

                      And look at the MySQL encryption functions AES_ENCRYPT() and DES_ENCRYPT()

                        Thanks for that Super.

                        I appreciate your help and I'll be sure to check out those links.

                          Both of these are also available in PHP's mcrypt extension (as DES and Rijndael), so you should be able to encrypt/decrypt on either side of the PHP/MySQL connection as appropriate.

                          Recall that if you're going to encrypt any data, it's only as secure as your decrypt key. Pick a key that's easy to guess or leave it somewhere it can be easily found and you might as well not have it at all.

                            Write a Reply...