|PHP Ghost Crypt||>||All threads||>||Version 1.5||>||(Un) Subscribe thread alerts|
Dave Smith - 2015-11-09 22:40:40
First off, if you are getting tired of hearing from me, then just let me know... or if you prefer to move the conversation into e-mail you can contact me directly at dave at wagontrader dot com.
Your current implementation is going to cause some problems for anyone who actually follows the instructions from the ghost hash thread. You should not be including it anywhere.
The idea was to create a self executing encrypted script. It is no longer a stand alone with the inclusion of the ghost hash class, you may as well have just moved all the functions into the ghost crypt class and included it every time.
To accomplish the stand alone part, the ghost hash is moved into the server operations by including it automatically. This way it is always available as part of the system. The neat part is, that it can also be used by any php script that wants to provide a secure hash, not only your ghost crypt.
There is also an important security consideration. Secret parts should never be stored with public parts. We accomplish this by getting the ghost hash file as far away from the public view as possible, ideally in a non web accessible part of the file system.
Consider this scenario... you have a 'super special' web site using some 'super secret' scripting that nobody else has been able to accomplish yet. You are also 'super busy', so you hire freelancers to do some of the 'super easy' upgrades, etc... The freelancers are given ftp access to the document root and sub folders, so you have encrypted the 'super secret' scripting to keep those curious freelancers from doing more than just their job.
It defeats everything to have the ghost hash file in the public space. When done properly, the freelancers from the above scenario can take the files away and play around with them for years and still never get to your code.
That said, there is the situation where someone will not have the permissions available to them to keep the ghost hash secret. They still can move it away from the public scripts using it and include it into the system, just to make it that much harder for someone to figure out what is going on with the encryption.
There will also be those users who don't need any level of security and will not want to go to any trouble setting up a secure system. You users on a free host, for example. Then it doesn't matter if the secret is in the same place as the public info.
In my opinion, any script dealing with encryption needs to take into consideration securing the information they are encrypting and should be developed to start at the most secure level and then fall back to less secure methods only if needed. For this, when encrypting...
1) You need to check if the ghost hash is available, and if so, use it for the encryption and decryption. Keep in mind you are not making it available by including it, it should already be available to the entire system.
2) If the ghost hash is not a method in the system, then fall back to the encryption and extraction code which does not use it.
Hope this all makes sense. If done with security as the top priority, your class will be one of the only ones in open source that is able to tick all the 'is it secure' boxes.
Nick Daniels - 2015-11-09 23:59:34 - In reply to message 1 from Dave Smith
I feel a lil foolish for that, As I wasn't fully understanding of what auto_prepend_file was, tho I now do. Cheers.
Now I have an understanding of what it does. I actually like it.
As for your points, I will surely have a go soon, either tonight or tomorrow.
Nick Daniels - 2015-11-10 00:31:37 - In reply to message 1 from Dave Smith
I got it now, As simple as the below lines, for check and fallback, which is rather simple as put.
$key = pack("H*", (method_exists("GhostHash", "returnHash"))?GhostHash::returnHash(md5($this->cryptKey)):md5($this->cryptKey));
$key = pack("H*", (method_exists("GhostHash", "returnHash"))?GhostHash::returnHash($cryptKey):$cryptKey);
_ Hopefully this is what you meant exactly. :)?
Dave Smith - 2015-11-10 01:52:48 - In reply to message 3 from Nick Daniels
Looks right to me, however this approach may force user to PHP 5.6 (?) because of the logic inside the pack statement.
Another possible problem with this approach is if a developer encrypts a file without implementing the ghost hash (because they don't care about the security) and distributes the self extracting files. If one of the users has the ghost hash implemented on their system, the script will fail to execute because it will use their ghost hash even if it wasn't used to encrypt. Okay, not likely, but possible.
If you actually did all the work in the encryption class and returned the appropriate decryption function, depending on whether ghost hash was used or not, the decryption would be a bit more stable.
Just a thought, however now that I see you understand how the ghost hash works, how you implement is now up to you :)
One last thing, as mentioned, the ghost hash can stand alone and have uses outside of your class. So, I am thinking of developing it into its own secure hash class. I absolutely love the naming, ghost(whatever) for security related classes. Do you have any objection to me using ghostHash for the class name developed outside of your ghostCrypt class? Feel free to object if you would prefer to keep the ghost(line) for yourself.
Nick Daniels - 2015-11-10 12:38:42 - In reply to message 4 from Dave Smith
I haven't any objection to it. Feel free. :)
Also The below is a good point, tho not likely, but could end up happening. - I'll have a think of a way. :)
" If one of the users has the ghost hash implemented on their system, the script will fail to execute because it will use their ghost hash even if it wasn't used to encrypt. Okay, not likely, but possible. "
Per Funke - 2015-11-11 11:22:07 - In reply to message 1 from Dave Smith
nice to see xperts have to think hard to make it work and also to get a walkaround in you brain
Dave Smith - 2015-11-11 13:41:56 - In reply to message 6 from Per Funke
You probably don't want to be running around in my head for too long, it would be a scary ride :)
This has actually been a project on my 'nice to have' list for some time, which is why I am taking a keen interest in it.
I am not sure if anyone realizes that what is currently out there for source code protection is either very complicated to implement or totally useless.
Imagine displaying the Hope Diamond and your theft prevention is only a sign that says... 'Please don't touch'. That is mostly what you get. This class however has potential.