encoding contents of table

[durangod]

hi i have a version control system and part of the system allows you to compare the difference between two php files.

Part of how this works is that when a file is modified a hash key is assigned to that file version and that hash is used a a key in the db. The other table that i use actually has the contents of the file itself. So basically all the file contents for the particular softare im working on are stored in the db and i dont like that because it is currently stored in the db field in readable fashion.

what i would like to do is hash the contents table field value (basically you would be hashing or encrypting the contents of the field) and then when need to view it or pull the contents for comparison i need to unhash it or unencrpt it to readalbe format.

i was considering using base 64 encode and then doing the base64 decode but i was told long ago that base64 is very easy to crack. I even considered using my ioncube encoder to encode the contents but not sure how i would handle this back and forth within the server.

I am asking because i am thinking this is quite different from just hashing a password or one field of data, we would be hashing a whole php file content from top to bottom. And then unhashing it to readable format when we need to use the file.

This being done in side of phpmyadmin what are my options here.

[Old Pedant]

Not to ask a dumb question...

Why would you worry about encrypting a file that you are saving in your own internal database??? Who are you concerned might be able to read the database/file? Surely you could put the info into a table or even a separate MySQL database and then put very strict controls on reading that table/db? You could limiit access to just one user account, for example, so that only a person with the username and password to that account could get to the data.

Note: base64 is *NOT* an encryption mechanism, at all. It would be worthless for any security purposes.

[durangod]

thanks for the feedback, my concern is that with the files stored open faced in the db it could lead to a break down in security. I am worried for the same reason that we even bother encrypting passwords as they too fall under the same principle.

Please understand that all the files are stored open faced in the db, including config files which contain db login as well as other files that contain security information. My concern is that storing them in this fashion bypasses any permission the file has on the server. For instance, if i set my config file to 644 im fine with that, but there it is sitting open faced in the db and if someone should happen to gain access to the db there it all is.

This software also allows for other users, these users are managed by the admin panel so that the users are created by the admin only in the event there may be several developers working on the software. In other words if my software firm happens to have 4 developers then as the admin i will set each of them up with a username and pw to access the developement area. But still even with that control i feel there still needs to be some kind of encryption on the db files being stored.

The purpose of the version control (revision control) software is simple. It allows an admin to upload a piece of software to the dir and allows several developers to work on the same software at the same time, including history notes of mods, tasks to complete, and all the other things you might expect such as checking a file out and then checking it back in when your done so that two differnt developers are not banging heads on the same file at the same time.

But again just like the necessity is there to encrypt passwords, i feel so is the necessity to somehow encrypt the file content area.

I hope that makes better sense.

[Old Pedant]

<shrug>If a file is 644 in the file system, then anybody can read it. I assume you really meant 600?

But why would you think that the file system is any more secure than the DB? Why would you think that it's easier to get permissions to see tables in the DB than it is to see files in the file system?

Each depends on a username plus password for access. If you are foolish enough to hand out the system administrator password to the file system, you have compromised your security. If you hand out the root password to the MySQL database, you have compromised your security.

I'm sorry, I simply can't see what the difference is. If you don't encrypt the raw files, then what is the point in encrypting them when they are in the DB?

But it's your system. Go for it, if you think it's worth the time and effort and inevitable problems.

[durangod]

sorry you are quite correct that was a typo i did mean 600, good catch.

I dont think its any more secure, i was just offering up an example, be it a bad one, trying to make a point that it is totally naked sitting in there, and also noone can read my config file from the server if they try to, but if they happen to have access to the db then yes they can because it is bare naked.

I am not talking about another developer seeing the file, they have access, they have full access other than admin functions because they need that access to develope the software. I am not worried about internal visuality, i am worried that if someone should happen be it rare to gain unauthorized access to the db, i want them to get encrypted garbage and not be able to see the file contents while viewing phpmyadmin or some other hack they may use.

I understand that maybe you dont agree that this is even necessary, so tell me this please. if that is the case why do we even bother encryping passwords, from what your saying its a waiste of time to even do that.

So what im trying to do is understand why it is important to encrypt passwords but yet the files themselves sitting in the db are wide open.

I not talking about encrypting the file sitting on the server dir ok, i can always ioncube that to feel better, but ioncube will not work inside the db, because (and im thinking this is correct) even with the loader installed it will only display the encrypted version if i view the file in my software not the readible version.

From my understanding ioncube passes thru the server php ini as it is read on the browser but my software pulls it direct from the db not the dir version so i dont think ioncube will cover that display path.

I do plan encrypting the source file when the software is done, but that is another challenge for other reasons. The main issue is that this software requires readable files when it pulls them, so i am trying to figure out a way to convert them back and forth in the process of access, reading, download, update, difference engine, all of that.

[Old Pedant]

We encrypt passwords so other developers won't know what they are.

Many people use patterns when creating passwords, so if you see two or three of their passwords, you can figure out the pattern and then use that knowledge to access other stuff they own that you shouldn't be able to reach.

I view that as an entirely different issue than encrypting *data*.

(And in many systems, passwords are not encrypted for ordinary users, just so that developers/admins can login as a user when something goes wrong. Certainly true in a system I administer.)

**********

Well, I guess I'm not as paranoid as you are. But go for it. Find a good 128-bit encryption package and use it. (Now, what do you do about having the encryption key *IN THE CODE*, since the code will need the encryption key in plain text in order to decrypt? This means that anybody who can read the code will be able to decrypt. So you've just moved the problem up one level, haven't you? How far will you chase your tail?)

[durangod]

but then again, thinking about my previous reply, it is a software that will be marketed for about 30 bucks. So in that sense i guess good enough is good enough as you so elequently put it in another thread. There is no sence building this as a 1000.00 piece of software when you get what you pay for.

So all in all i guess the answer is leave it as is, its designed more as an internal dev tool than it is as a public function. So i will just let it be and let the admin whoever that may be handle the security thru the admin fuctions available and their own local server security.

thanks

update, chasing my tail lol you just made my day with that one bud. totally, and you are quite correct... very good reply...