I have some PHP source code that I'm hosting with hosting company XYZ. I'm using a PHP encryption software like Zend Guard or ionCube to protect the source from being viewed by anyone (sysadmin or hacker that hacks the sysadmin).
How easy/hard is it for someone who has full access to the system (like the sysadmin or hacker that hacks the sysadmin) to decrypt the source? I don't know how encryption software work, but I'm assuming they use some key, which would have to stay on the server and is therefore accessible to a sysadmin or a hacker. If you're technically-knowledgeable about the how-to, don't hesitate to offer an explanation in your answer.
Does the use of such source encryption slow down the site? If anyone has first-hand experience or knows from someone that has first-hand experience ;)
I'm interested in the technical aspects of this, how effective encryption is.. and its disadvantages, from those who used them or considered using them
Thanks (all helpful answers/comments are up voted)
Edit: the answers so far seem to be ignoring what I'm trying to understand.. I'm trying to understand the effectiveness of encryption. I don't really have any code that needs protection from the bad guys, the above was just an example, so advice like open source it or hire a lawyer don't really address my technical curiosity.. A+ to anyone who gets the point
Encryption (or encoder) schemes try to hide your code as an encrypted file. Obviously, the code has to be decrypted at execution time, which adds useless overhead.
Some of these also insist that the host system install special routines, which the hosters intensely dislike, because they don't want to set up special configurations just for you. But the bad part is that they contain the seeds of their own undoing: to run on the target host, they must contain the decryption software. So if you use one, you deliver the very decryptor necessary to get at your code. Its only a matter of locating it; once found, your code is completely decryptable and exposed. These simply aren't safe.
Obfuscation schemes scramble the names of identifiers, remove comments and formatting. But the obfuscated code runs exactly like the original, with no overhead and no special runtime support needed. Obfuscators depend on the inherent difficulty in understanding programs in general. Programs are hard enough to understand when they are well designed, names are well chosen, and there are good comments in the code. We all hope our programs are well designed, but if the names are bad and the comments are gone, they're pretty hard to understand. Examine your own experience with other people's code.
People will say, "but anybody can inspect obfuscated code and understand it". That's true if you have a tiny application. If your application has any scale (tens of pages of code) it is extremely hard to understand what it is doing when all the variable names are scrambled. The bigger your code, the better obfuscation is at protecting it.
If you want to see examples of what one PHP obfuscator does, see our Thicket PHP Obfuscator.
Neither Zend Guard nor ionCube uses encryption, in it's mathematical sense, to protect your code. What they do, except the obfuscation already described by other answers, is encoding.
This is a process that's normally done automatically by the PHP interpreter each time your script is accessed - your PHP script is compiled into a bytecode format, that's then executed. What encoders like Zend Guard and ionCube essentially does is an equivalent process, only that it's done once, and then only the "compiled" bytecode is made available/uploaded to the server.
This means that actually recreating the very same code that you once wrote is entirely impossible. What is not impossible, and this goes for obfuscation as well, is reverse-engineering the compiled or obfuscated code to figure out what it's doing.
To summarize, I'd say that these products are very good at protecting your code - as opposed to protecting your logic.
Why exactly do you need to encrypt your source code? If you are sporting this as a safe-guard against potential hackers, then please believe when I say that if they really wanted to decrypt your source code, they would do it. It is possible with ionCube, last time I checked.
As far as performance impacts, I believe Zend is a tad bit faster than ionCube due to it not requiring any extra files. But like I said before, don't rely on encryption for anything.
If it can be executed it can be decompiled. Stick to your legal team for rights access, not encryption :) Better yet, open source your project :P
EDIT: 'Encryption' also adds heavily to execution times!
The only thing you can do against the hosting company is to have a good license and lawyer
As far as I know, PHP encoders do not actually encode you PHP code. They just change variable names and add unnecessary rubbish code, so that it becames VERY hard for anyone to find out, what the code does. The problem is that they cannot hide any password (be it the hard coded admin password, or the database connection data).
So they do not ensure that your code is safe, they just make it very hard for anyone to understand it.
Related
I need to implement a simple (not ultra-secure) but fast file en/decryption using PHP, so files are encrypted on upload and decrypted on download. Files are mainly images (jpg) and videos (mp4), and some videos are up to 30 MB, so my idea is to encrypt only the first X bytes of each file, just to avoid anyone that could have access to the server (ie. support people) to open the files from users.
I am new to this subject and after almost 6 hours researching found only old examples, using deprecated Mcrypt.
Please, can anyone give me tips to start? Is there any native method from PHP that I can use, or maybe an open-source library? Does Mcrypt would be an option, even if deprecated (I am using PHP 5.6). Do you think encrypting only the first X bytes of the file is a good approach in my case?
Thanks!
Here is a PHP encryption library: https://github.com/defuse/php-encryption
I found this just by googling, I can't vouch for it's reliability or security. There are documentation and examples on that page.
However I really would ask you to take a step back and consider what the purpose of this is and what the wider security considerations are. In order to do this successfully then there will need to be some security secret, either a key or a password, that will need to be kept hidden from the people that you don't want to be able to decipher the data. I can imagine that would be difficult if those people are the support staff. If you made the password the users login password you are setting yourself up for widespread data loss when a user forgets their password. Also at some point it will need to be unencrypted and you will need to think about making sure that is not leaked at this point. And then you need to think about who has access to the source code that handles the file access, and the key/password code. What about server logs and caches? Etc etc
Furthermore if you are only encrypting the first X number of bytes and don't need to make it 'ultra-secure' then I wonder why you are attempting to do it this way at all? I'm not sure what problem it is you are trying to solve.
Given that doing encryption properly is not simple (not to mention costly in terms of computing resources), but if you don't do it properly it isn't much good then I can't help suspect you will probably be much better off spending the effort making sure that untrusted persons only access information on a need-to-know basis and all access is logged in order to keep people honest.
i started learning a bit about mysql and while i was reading i was thinking that the security vulnerabilities on mysql are pretty immense and can't be well covered if someone doesn't truly understand pretty much everything about mysql.
if i have a website that will store not a very big volume of information, would it be bad to store it in .php files?
what are the implications and vulnerabilities of this?
it seems to me that the risk is far smaller because if the .php file doesn't have an echo statement, if you try to access it all you get is a blank page, and if you are unable to 'send code' by user input and send files to the website it should be secure as far as the website is concerned (obviously that if the server itself is hacked the attacker pretty much has the control of everything but that's not the point on this matter)
update to the question.
it seems that what i've written above isn't producing the kind of answers that i expect and so i will try to simplify.
what i'm looking for here is why are databases more secure than flat files without bias because most people i've read stuff about on this subject will just say databases are more secure but can't say why. yes they're faster and it's easier to manipulate the data especially if it's complex or with multiple users and there is a lot of info. about that and it's easy to understand why.
the fact is that when i started reading about mysql a few days ago i saw that if your php is compromised most likely so are the databases so writing good secure php code is probably the first and most important line of defense to your mysql databases.
if your php is uncompromised so is the information you stored in php files so if you write good secure php, the security of plain php files will be good.
having databases also makes you use php functions that usually you wouldn't use and some of them possess real security holes that have to be "patched up" so writing good secure php code to work with databases is more complex than writing equally secure code to work with plain files.
also when you have apache/php/mysql installed you have 3 things that may have entry points for hackers if they're not correctly configured and maintained, if you cut mysql loose you only have 2, you won't have to bother with sql injection for example because with no databases that's impossible to happen, you may inject all sql you want but you will get nothing.
so for managing small amounts of data, plain files seem to me like a secure, a bit more complicated to work with the data, slower but not relevant considering that it's a small amount of data we are talking about.
why may these deductions be wrong is the information i'm looking for with this.
Apples and oranges.
You can go to a drag race with a Hummer and complete the race but you will surely be in last compared to a Bugatti. Take a Bugatti off-road and it will definitely fall behind the Hummer.
PHP is a server side scripting language. Data storage and retrieval is not the primary consideration in PHP.
mySQL is a relational database management system. It's design is 100% purposed for data storage, retrieval, and security.
What's your plan for data storage and retrieval in PHP? It seems like will have to do a lot of unnecessary work re-inventing the wheel to achieve this. Why would you?
Without understanding what security concerns you are specifically worried about in mySQL there isn't much more to add.
Edit: An article calling out the general differences.
These two points will cover most security issues:
1)Learn PDO and the prepared statement protocol. This will take care of most if not all SQL injection issues. Do not send raw SQL to a database.
2)Sanitize all your GET and POST data that comes into PHP. This will take care of most XSS.
Many frameworks in other languages do this for you, but the PHP newbie will just use bare PHP and open himself up to all kinds of attacks. That is why PHP is "unsafe."
Read up on security, and try to implement some of the pointers that you feel are important. No language, framework, platform, etc is 100% secure. Just like everything else in life, you take as many steps as possible to minimize the risk.
I am now working on a php project(Internet Shop) that will possibly deal with storing locally customer credit card information.
So I was thinking among other things about encrypting php files with IonCube, especially those containing settings(encryption/decryption key, IV) for
symmetric encryption algorythm. So I'm not sure if it will add an extra layer of security or not, since it appears IonCube-encrypted
files and similar solutions can be decryped.
Thank you!
IonCube is not a suitable solution here. If you encode a file which contains something along the lines of:
<?php $SecretValue = "xyzzy"; ?>
It's still trivial to recover the secret value:
<?php require("encoded.secrets.php"); print $SecretValue; ?>
So the IonCube encoding is basically worthless here.
ionCube and Zend are fine for code protection, and even if some decompilation service produced usable code from an encoded file, this would typically do little if anything to diminish the benefits from encoding and license enforcement, and may even result in increased revenue in the longer term for the software provider.
Data hiding, however, is entirely different. Keep in mind that PHP and all of the associated library wrappers, plus the libraries themselves, are opensource and therefore easily modified. Data sent into and returned from any PHP function can be easily exposed by simple changes to the PHP internals. Want to see the database password to MySQL? Just modify the mysql_connect() wrapper or the underlying MySQL library and log the details. Some encoding systems, for example ionCube, can encrypt non-PHP files and then decrypt at runtime via closed source routines in their runtime component, which may in some cases provide some benefits over the opensource PHP routines such as mcrypt.
duskwuff is not entirely incorrect with the example cited as in some systems, ionCube for example, it is possible to protect files from being included by non-encoded files, or files encoded by a different copy of the Encoder through a mechanism called "include attack protection". None the less, storing sensitive data in variables, particularly globals is a poor approach, and it would be better to have such data returned by a function with a misleading name and that perhaps performs differently unless called in a particular way. e.g. a function called mytime() that does return the time unless called with a "magic" value.
If you're going to encode/encrypt your files, Zend Guard is supposed to be one of the best, but as others have said, if they can get to your files that's the least of your worries.
I'm a relative newbie to PHP and just making my way through the W3Schools tut.
The tut makes a big point of saying you must always filter external data (i.e. cookies, form data etc).
I'm writing a fairly simple system that talks with a third party Joomla extension. It's at a prototype stage where I'm just wanting to demonstrate the functionality in a minimum viable product.
Basically, I'd like to know... what's the worst that could happen in I don't filter content. Are we talking 'I might get a bunch of spam', or 'a good hacker could get root server access'?
Have hunted around online, but would love any of your experience / insight on the matter!
If you don't filter the input data, your site will probably be prone to an SQL injection attack. Check this site. It contains a humorous comic, quite famous too. It depicts the problem of SQL injection quite clearly :).
A good hacker could theoretically get root access.
If you don't filter content that goes into database queries, the database will run whatever was put into the query.
In that case, the hacker might be able to download a database full of usernames and passwords. Which you certainly don't want. Especially if your root passwords are in there because you've used the same password twice. Or they might just delete your database altogether. I've read reports of that happening.
My php user authentication script is based on code from someone who, at the time, was a much better coder than me. As such I trusted that the parts I didn't quite see the point of were better left alone unless I had a good reason to change them. I've since improved and have my own ideas of what should be done.
One of the things in this script is allow you to define (and easily change) a custom name for the html login and password fields.
I guess if someone is trying to brute force their way into an account this would allow you to confuse their script until they notice and react, but otherwise I just don't see the point.
Can anyone explain any real benefit of this before I simplify my script and strip this out?
I'm afraid there is no real benefit at all, password fields will always be type="password" in HTML which alone pretty much proves the pointlessness.
Other reasons against, any client side app will look at the HTTP requests and responses or the 'password' input (can still do both), intermediary attacks will look at HTTP / TCP packets, and brute force attacks will still brute force (although why they'd bruteforce a 'login' to a site rather than ssh, open ports or try to use known exploits is beyond me.
Hope that helps
It's usually an attempt to avoid automatic spiders crawling for login pages that they might be able to brute-force. Whether or not it's effective is questionable; but either way if you think it makes the code more complex than it should be, then it probably shouldn't be there.
This is probably used to prevent attacks targeting many computers, ie. not a brute force which tries to access your website, but attacks which tries to access any website within a range of IP addresses.
I frequently see in server logs attacks trying to exploit old phpMyAdmin bugs or other frequently used services, even if I don't have any phpMyAdmin on my website. This is quite similar.
Security by Obscurity is no kind of security!
I could just search for input fields and assume that the first one was login and the second one of type="password" is password on the form regardless of their names. This won't stop anyone with even a passing knowledge of HTML and Javascript. A simple Python program using Beautiful Soup and 10 minutes will by pass this "security" for just about anyone that wants to. The barrier to entry of Python, HTML and Javascript is extremely low.
If anyone thinks different they haven't had to deal with having to patch up systems that were breached over and over because of "clever" "security" because these bad assumptions that "it makes it not worth it", if there is money even small amounts of money, it will be worth it for someone out there in the world, that has free time and no other income. And that doesn't even begin to cover the worse problem which is the oft denegrated "script kiddie" griefers that hack things just to be hacking them and causing havoc for fun.
The only advantage I can think of is that with all of the easily exploitable websites out there, attackers probably won't even bother with yours if it takes even minimal effort. I'm not sure if it's useful if these things don't change automatically though (since you're not likely to change them manually very often).
On the other hand, if your passwords are vulnerable to a dictionary attack, it's unlikely that anyone would ever break them like this anyway.