tedd wrote: > And then there is the security involved in what happens *if* your > server is hacked and all your "private" data is seen by a third > party. What does all that entail -- and -- how you might be able > protect yourself should be paramount in every developer's mind.
IMHO, not in a normal context. A developer needs to be able to trust that the server is as secure as the organisation expects. > In addition, access to the database can happen if the user-name and > password are kept in a file, or code, that is exposed to the hacker > after hacking. Everything is exposed. If somebody gains unauthorized access to your system, assume the worst. > Now, how likely is it that a server might be hacked -- again, I don't > know. If it's not secured, 100%. > So, if you want to secure your data on a server, it means that you > should take steps to do that and not rely upon the host to do that > for you. Like I said, it would be nice to have a server guru wade in > on this to clarify things. There isn't really a lot to clarify. To reduce the risk of a server being compromised: impose physical access controls. limit the open services, and run a firewall. make sure your open services are secure (latest patches etc). To reduce the impact should it get compromised anyway: run your server in a DMZ. run SElinux or AppArmor for access control. do not store important passwords on the server. If all of that isn't really within your reach because you don't have your own server - get your own server and secure it. A leased server is available for e.g. EUR50/month and that money is better spent than you spending hour after hour trying to secure your application to run on an insecure server. -- Per Jessen, Zürich (10.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
