thanks for your answer

from what you've written I have a feeling it's maybe not such a good idea to put all that stuff online after all ....

thanks again

    I'd say just use HTTP authentication using whatever mechanism is built into your web server for providing this.

    Web servers are well tested pieces of software and unlikely to contain bugs which let people get past HTTP authentication.

    Mark

      I don't know what HTTP authentication is - but I'm off to find out

      thanks 🙂

        HTTP authentication only offers a method of password protecting HTTP access to your sensitive data.

        This is fine for most purposes but it will not protect your data from being accessed by anyone who has access to the server via other means (someone with physical access, root access or someone who manages to exploit a security hole in any of the server's running processes for example).

        You may consider this overly paranoid, but 'how secure' it needs to be depends on how sensitive the data is. How disastrous would it be if someone was to get hold of your client's passwords? What damage could be done with them passwords, etc?

        Personally if I was doing this, I would additionally encrypt the data stored on the server, so even if someone gets hold of it, it would be next to useless to them to get anything out of it, or at least make it very troublesome for them. Your PHP can do the decryption when you supply it with a decent passphrase only you will know. Also make sure you use SSL when accessing your PHP page so that nothing is passed over the net in plaintext.

        As kakki says though, there is no "absolutely foolproof" method... you can only make sure you get as close to foolproof as needed for the data your storing.

          Forgot to say, if you have a mobile phone that can run Java apps, there are plenty of password manager utilities that you could try that will store your passwords, etc, fully encrypted. This is what I do and I find it really useful. Has got me out of trouble once or twice when I wouldn't have had internet access too.

            dotnotwhat wrote:

            Personally if I was doing this, I would additionally encrypt the data stored on the server, so even if someone gets hold of it, it would be next to useless to them to get anything out of it, or at least make it very troublesome for them. Your PHP can do the decryption when you supply it with a decent passphrase only you will know.

            what's this kind of encryption called ?
            would you by any chance have a link to an online resource where i could read up about it ?

            thanks

              You will need to use two-way encryption so that you can get your data back into plaintext to display it (opposed to things like MD5 and SHA1 which are one-way). You can do this with PHP's Mcrypt functions or with more tinkering, using something like GPG.

              PHP Freaks has an introduction to Mcrypt and PHP which might be useful. They build some simple to use functions that you can probably use for the encyption and decyption processes. I think they embed their secret key in their PHP code, but you could modify it so you supply it via a form field on your web page.

              Also, there's PHP's manual pages for Mcrypt.

                In almost every case, if you need encryption (and trust me, you'd better NEED it if you're going to use it), the application is the wrong place to put it.

                Your operating system supports encrypted filesystems and/or block devices- if you feel that you need to encrypt data on disc, use those.

                Your web server supports encrypted connections- if you want protect data in transit, use that.

                Think about who you're trying to protect data from. If you're encrypting data on the server locally, who are you defending against? Where are you going to store the key? Because someone who has compromised the server WILL be able to obtain the key.

                Mark

                  What's wrong with storing the key in your head? As long as you can come up with a decent length / cryptic key that you can also remember in your head, then there's no need to leave it on the server. If you were to leave it on the server, I'd say it's arguably not worth doing at all.

                  An encrypted file system could be useful, especially protecting against physical data theft of the server itself, etc, but once the file system is mounted on the server so PHP can read and write to it, it would be trivial for an attacker with root access to also gain simple access. I don't think it actually offers much more protection over a non-encrypted file system in this situation.

                  Mcrypt is not hard to use and if you keep the key to yourself, nobody is going to be getting at your data without that key... not without a fight any way!

                    Someone who compromises your server can modify its software such that it records the key as soon as it is entered (or sends a copy of the decrypted data).

                    As such, this method provides no security against your server being compromised, or at least no more than using an encrypted filesystem.

                    Moreover, application level encryption will massively complicate your application and defeat some kinds of optimisation (caching, indexing etc)

                    Mark

                      Quite true...

                      I don't think there is any perfect answer for this scenario, especially if you don't have full control of the web server in question.

                      I suppose you could use Javascript to do the encryption and decryption on the client side (using AES for example) which would work for a simple app like this, but then that still leaves the possibility that someone with access to the server modifies the javascript code, etc....

                        Write a Reply...