| 11:57 am on Jan 10, 2003 (gmt 0)|
If you can teach your app to have access the the mySQL table, then you already have enough knowledge to access it yourself.
| 12:02 pm on Jan 10, 2003 (gmt 0)|
Could you encrypt the actual data inserted so that only the person with the correct key can understand it despite the fact that you as the admin will still be able to see it?
| 12:04 pm on Jan 10, 2003 (gmt 0)|
That's exactly what I was thinking..
| 5:07 pm on Jan 10, 2003 (gmt 0)|
So, we think it possible to protect the data from the admin?
What about getting the table size, anyone?
| 5:19 pm on Jan 10, 2003 (gmt 0)|
|So, we think it possible to protect the data from the admin? |
I would think so. If you encrypt the data on insert it will be inserted so that it couldn't be read even by PHPMyAdmin. The only way to read that data would be to use MySQL/PHP to query the db and pull the records. Now the only way to personalize it would be to either use logins and hash the pwd or use personal certificates.
| 5:21 pm on Jan 10, 2003 (gmt 0)|
Yeah, I'd keep a seperate table of username/pass info with the pass md5()'d. Sounds secure enough to me..
No thoughts on getting the size of a users table guys?
| 5:35 pm on Jan 10, 2003 (gmt 0)|
I know you can do it I am just having trouble remembering how exactly I've done it.
this looks promising
| 8:28 pm on Jan 10, 2003 (gmt 0)|
Many thanks Jatar, the first appears to do it. Now all I got to do is work out how to USE the data it spits out ;)
More reading, but another day, got to watch a movie now :)
| 9:33 pm on Jan 10, 2003 (gmt 0)|
>>how to USE the data it spits out
I was having the same thoughts there should be something on php.net under mysql functions.
| 10:27 pm on Jan 10, 2003 (gmt 0)|
The db directory holds three files for each table:
A data (.ISD or .MYD) file, an index (.ISM or .MYI) file, and a data dictionary (.frm) file.
Kind of clunky but I guess you could just add up their sizes for resource use total.
| 3:31 am on Jan 11, 2003 (gmt 0)|
If you do go the encryption route (best bet) then why not just use phpadmin to read the table stats?
| 6:54 pm on Jan 11, 2003 (gmt 0)|
Nick, could you sum up how you intend to Protect users tables from yourself. After having read this thread I am not entirely convinced that a solution to your problem was suggested.
I am not sure whether there is such a solution at all (at least when there are only two parties involved).
Your application would need to encrypt the data. Symmetric encryption is not an option. You would have the key to encrypt the data and could use it to decrypt the data. So the only way to go would be to use some sort of asymmetric encryption. Using the public key you could encrypt the data. But your app would not be able to decrypt the data. You would need the private key for that. If you supplied a way to upload that private key to the server and use it in your app you would need a way to ensure that you do not have access to the private key. Your application would need to encrypt the key. Symmetric encryption is not an option... ;)
I believe the way to go would be to decrypt the data on the client side using a Java thingy or some kind of proxy server or have a third party involved. But even then your clients would have to at least trust that third party.
If you really want to do something like this have a look at the FreenetProject. This might give you some ideas.
| 6:58 pm on Jan 11, 2003 (gmt 0)|
Thanks andreas. Good points.
| 7:07 pm on Jan 11, 2003 (gmt 0)|
Basically, my understanding would be that you would need 1 table with a plaintext username and a 1 way has of the user's password. The original password would then be the key for the symetrical encrpytion/decryption of the rest of the data and would not be stored on the server. This setup would prevent you from being able to view the data by having access to the database alone, but you can still edit the scripts to store the incoming passwords at any point and thus have access. So basically, I think andreas is correct in that the encryption/decryption process needs to occur in some trusted environment (either third party or local to the client machine).
| 7:17 pm on Jan 11, 2003 (gmt 0)|
Yes, eventually doing business with somebody is about trusting the other party to do what they promised in the contract.
Personally I would not have anybody else have access to extremely sensitive data. I would store it on an encrypted partition on my own computer which is not connected to the net in any way.
Only if you were to provide a way to store illegal data would I suggest you make 100% sure that you do not have any way of knowing what is actually stored because then the CPS/DA/StA would not be able to prove that you knew what was stored and the court would have to assume that you did not know what was stored or that what is stored and could not be decrypted is legal rather than illegal. This is the way how the FreeProject works. But even the you need to have some kind of "trusted environment", i.e. a jurisdiction that actually heeds basic procedural human rights.
The bottom line: Interaction is inherently insecure. Without interaction there really isnīt anything to life ;)
| 7:22 pm on Jan 11, 2003 (gmt 0)|
|But even then your clients would have to at least trust that third party. |
I can understand that people would be more willing to trust a third party than Nick_W, moderator of the CSS [webmasterworld.com] at WebmasterWorld ;)
And no, Iīm not a cheeky *** ;)
[edited by: eelixduppy at 9:55 pm (utc) on Feb. 18, 2009]
| 7:29 pm on Jan 11, 2003 (gmt 0)|
The other option would be to make the database dowmloadable with an installer. Then folks could run it locally or on their website.
If they ran it on their website, the admin could still view it but it would not be such a big detail. The information is what one webmaster would not want another webmaster seeing. It's not the blueprints to fort knox ;)
Lot's of thinking to do....