Re: [PHP] Secure Communication?
At 3:58 PM -0400 8/30/10, Paul M Foster wrote: 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: You got the method correct -- unfortunately, it's not as secure as I need. As for it being an academic exercise, nothing is academic. If it works, it's implemented, if not, it isn't. That's what we do for a living. I will say it was learning experience, in that aspect it was academic. :-) Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
At 2:23 AM +0200 8/30/10, Bostjan Skufca wrote: 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. Hi Bostjan: 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. Thanks, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
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
Re: [PHP] Secure Communication?
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
Re: [PHP] Secure Communication?
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. Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
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. First thought - you're reinventing the wheel. When I connect to a server via https, I have secure communication. -- Per Jessen, Zürich (16.5°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
Per Jessen wrote: 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. First thought - you're reinventing the wheel. When I connect to a server via https, I have secure communication. First, it isn't the connection that he is trying to secure. He admits to using HTTPS in his connections already. What I think he is trying to prevent (correct me if I'm wrong) is access to the data on the opposite server. He wants to make sure that the access to this data is only able to be done by the remote server. Hence why he said that the key to the local data is located only on the remote server. So, my guess would be that the key would only be usable by the remote server. It would not work on the local server. Jim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
At 10:31 AM -0700 8/29/10, Jim Lucas wrote: Per Jessen wrote: 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. First thought - you're reinventing the wheel. When I connect to a server via https, I have secure communication. First, it isn't the connection that he is trying to secure. He admits to using HTTPS in his connections already. What I think he is trying to prevent (correct me if I'm wrong) is access to the data on the opposite server. He wants to make sure that the access to this data is only able to be done by the remote server. Hence why he said that the key to the local data is located only on the remote server. So, my guess would be that the key would only be usable by the remote server. It would not work on the local server. Jim: Bingo. That's it. Sometimes it's hard for people to fully understand what I am saying even when I explain it in great detail. Often people respond with what they feel is an obvious solution when the statement is much more complicated than that. Like in this example, I use HTTPS in all the steps yet one responder said use HTTPS. That means: 1) He didn't understand what I was saying; 2) He didn't read what I wrote, which probably the reason for #1. Also, as per another responders statement, using a SSL does not necessarily mean that the server is more secure. In the case I am working on the host has a SSL, but I am still going this length because of the possibility that the server may be hacked. The SSL only assures visitors to the host that the host is who the host claims to be. It does not assure, nor prevent, in any way that the server may not be hacked -- am I wrong? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
Jim Lucas wrote: Per Jessen wrote: 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. First thought - you're reinventing the wheel. When I connect to a server via https, I have secure communication. First, it isn't the connection that he is trying to secure. He admits to using HTTPS in his connections already. I didn't bother reading far enough I guess. What I think he is trying to prevent (correct me if I'm wrong) is access to the data on the opposite server. He wants to make sure that the access to this data is only able to be done by the remote server. If that is the objective, it's perhaps best solved by using TLS with a client certificate/key. Well, that's what I would do. -- Per Jessen, Zürich (15.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
tedd wrote: Like in this example, I use HTTPS in all the steps yet one responder said use HTTPS. That means: 1) He didn't understand what I was saying; 2) He didn't read what I wrote, which probably the reason for #1. You said secure communication, which (in this context) is quite clearly HTTP + TLS. I didn't bother reading the rest because I had already had trouble understanding your previous questions. Also, as per another responders statement, using a SSL does not necessarily mean that the server is more secure. Yes, it has no bearing on the security of the server, but using TLS means the communication is. If you then also use client-side certificates, you're really quite safe. -- Per Jessen, Zürich (15.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
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
Re: [PHP] Secure Communication?
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.sperl...@gmail.com 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
