On 29 August 2010 18:24, tedd <t...@sperling.com> 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?

A) I wouldn't want to reinvent the wheel but would use
SSL/certificates/something to that effect (it's a whole lot more
secure than your setup), and B) there's nothing in this setup that
secures you from someone hacking Master and just sucking out data from
that machine.


WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to