On Sun, Aug 29, 2010 at 12:24:31PM -0400, tedd wrote: > Hi gangl: > > I realize that the problem stated herein has been solved by others, > so I'm not claiming I've done anything new -- it's only new to me. It > was a learning experience for *me* and my solution may help others. > > In any event, I've finished creating a method for establishing what I > think is secure communication between two servers. I've written two > scripts that run on different servers, which confirm communication > between them via hard-wired urls and creating/writing/reading a > url-confirmation file. > > The purpose of this exercise was to simply to keep database-access > data (i.e., user_name, password, key to decryption) secret. However, > the secret could be anything you want to keep secret -- secret being > defined as no data residing on the server of concern while allowing > that server access to the data when needed and under authorization. > > Here's what I've done -- I have two domains, namely webbytedd.com > (the Master) and php1.net (the Slave) -- both domains reside on > different servers. The domain names really don't matter, it's just > that this method currently works between those two domains. > > Statement of Requirements: > > 1. The Master requires "access" to it's database. > > 2. The Slave keeps "access" to Master's database in it's own database. > > 3. It's required that "access" remain secret in the event that the > Master is hacked. > > *The term "access" above is defined as database-access data, such as > user_name, password, and key to decryption. > > Description of Method: > > 1. When the Master wants access to it's database, it first creates a > url-confirmation file and writes a token to that file, which resides > on the Master. I've used time() as the token, but the token could be > any variable -- it really doesn't make much difference other than the > value should be different each time. > > 2. The Master then sends a cURL request to the Slave via a POST where > the POST variable contains the token. > > 3. The Slave when receiving the POST request from Master reads the > token from the newly created url-confirmation file residing on the > Master and then compares that token with the token provided by the > POST -- if the tokens match, then the Slave returns "the access" to > the Master. If not, the process fails. > > 4. After receiving "access" the Master deletes the url-confirmation > file and continues with it operation. If the Master does not receive > "access" then it deletes the url-confirmation file and exits. > > This method sounds simple enough and does several things. > > 1. There is no "access" stored on the Master. > > 2. While the Slave has "access" for the Master stored in its > database, the access to the Slave's database is kept in an > out-of-root (not open to the web) file. Note, in this case, this was > not possible on the Master because the host did not allow out-of-root > files -- but that is only tangential to the problem addressed here. > > 3. If a hacker did obtain access to the Slave database, then the > hacker would discover the contents have been encrypted and only the > Master has the decryption key kept in it's database. > > 4. If a hacker did obtain access to the code residing on the Master, > then the hacker could not access the Master's database because the > "access" data is recorded on another server (i.e., Slave). > Furthermore, the hacker could not get the code to run anywhere else > because the Slave's "look-up URL" for the url-confirmation file is > hardwired to the Master address. > > 5. And lastly, all communication between both domains is done via https. > > Now, for the exception of both server's being hacked at the same > time, what could go wrong? > > Cheers, > > tedd A couple of things I'm unsure about. Here's what I *think* is going on: The actual database with the Master's data is located on the Master machine. The "keys" to this data are contained on the Slave server, in *its* database. The Slave's database is encrypted, so that the "keys" to the Master database can't be derived even if a hacker hacks the "Slave" machine. The "keys" to the Slave database are held by the Master. So when the Master asks the Slave for access, it must send across the keys for the Slave to access its own database. The Slave then decodes its database and sends the Master back the "keys" for the Master's database. The Master can then make queries to its database unfettered. Is that about right? Other than the fact that this solution should be rife with latency issues, it seems like it would be secure. I assume you're doing this as an academic exercise. If you had an actual client who wanted to go to this much trouble to secure their data, I think I would opt for the previously suggested solution of getting a dedicated server or two. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
