At 2:23 AM +0200 8/30/10, Bostjan Skufca wrote:
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
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
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,
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.
A very detailed and correct analysis of what I was trying to achieve.
Your comments are well said,appreciated, and acknowledged.
I was hoping for a solution, but I see there is none.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php