Hi tedd! Reading this thread I assume you are doing RPC stuff when you are expressing yourself as "the access" to database, which normaly describes direct access to database. In your case, you should divide the phrase "hacked server" into two separate types of incidents (let's talk about your "master" server here): 1) server gets cracked and your code gets exposed in read only mode 2) server gets cracked and cracker can modify your code (read the definitions of hacker vs cracker for further communication:) In case 2) there is not much you can do, because they have everything they need to access database in a fashion of their desire. However, in a case 1) your protection works fine. But it is wheel reinvented, for 99% of a population. Why? When most of people are thinking of security, one of the first thoughts is getting off shared hosting. When you do that, all you need to set up is two way SSL authentication and IP checking. Which could be done without the RPC layer (for example MySQL can check cert against with host IP, cert against CA and CN checking and all). Anyway, what you are trying to achieve is to connect two systems which are shared hosting based. In this case your solution is somehow "secure", if there is such a thing. That means that it is secure by it's nature. But what you have to be careful about is implementation and things that are out of scope of setup you have described. One possible breach of your "secure" setup is here: on your master server (shared hosting) HTTP server runs PHP scripts as single user (usually www-data, www or nobody). Your script HAS to have writable permissions to folder where it publishes tokens. Should malicious user have an account on the very same machine, she can also put files in folder where only you should be able to do so. This way, she can publish token, request stuff from your database and decrypt it using your keys. I hope I have understood your intentions correctly. Best regards, b. PS: Probability of hacked server. >From my experience majority of successfull breaches come from 3 methods (in order of decreasing frequency): - password collection with viruses/trojans and such (operates against client machine) - stupid users writing passwords all around (post-it, forwarded email, etc) and/or social engineering (operates against user) - brute force password guessing (operates against server) Only tiny fraction of breaches are whole servers being hacked/rooted. On 29 August 2010 23:18, tedd <tedd.sperling@xxxxxxxxx> wrote: > To all: > > Part of the problem in discussing security is that there are all sorts of > security issues. > > There is the obvious cleaning and scrubbing of data coming into your site > from outside sources such as from POST, GET, COOKIES, and such. > > There's the security problem of communication between your users and your > server, thus HTTPS and SSL's come into play. > > There is the security problem in what access your users have to your data, > such as in setting directory permissions, placing files out-of-the-root, > placing data in a database and controlling users access to such data. > > 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. > > Now, I'm not a server guy, nor do I know what happens when a server is > hacked, nor do I know what data might be exposed. I will say it would be > nice to have a server guru, like Daniel Brown, wade in on this and tell us > what is the range of things that can actually happen and what data might be > exposed and how we might protect ourselves. > > At this point, I don't know the answers to those questions, but in my > readings I found that if a server is hacked, then all data contained on the > site can be read by a third party. Even encrypted data can be decrypted *if* > the keys are exposed. 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. > > As such, that was my recent concern and my subsequent "Secure > Communication?" post -- it was a way to protect data. > > Now, how likely is it that a server might be hacked -- again, I don't know. > However, I sent numerous emails corresponding with GoDaddy.com as to what > they would do *if* their servers were hacked and their customer's sensitive > data was exposed to a third party, which caused their customers harm. > > I assumed that GoDaddy.com had insurance policies and procedures in place > to mitigate damages for their customers, but unfortunately they responded > that each case would be handled on a "We'll see" basis -- and I think we all > know what that means. > > 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. > > > Cheers, > > tedd > > -- > ------- > http://sperling.com/ > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
