I'm thinking of protecting my script to the mass majority of users (non-web dev savvy) and I came across an online service to encode php script. I'm not sure about it though.
Is it safe to encrypt php script? What if the encoded code has something fishy in it?
If you intend to distribute the PHP file then I would suggest that you do not do this. It's only going to irritate those that want to tinker with it.
If for some reason you don't want them tinkering with it, then don't distribute the PHP file.
If you need to distribute the file AND you don't want them tinkering with it, then I would highly suggest you not do this in PHP and instead write the functionality using C as an extension to PHP.
You'll notice that at no point do I suggest you actually go ahead and "encode" the php file. That's not going to buy you anything.
If you are looking to obfuscate your server-side PHP, the best bet would be to use a commercial product such as Zend Guard (http://www.zend.com/en/products/guard/). Any home-brew encryption is not secure in the slightest - your code can be easily reverse-engineered with fairly trivial effort. The page you link to does not have any credibility, it is just someone's side project. They have no accountability or stake in protecting your information.
Even these commercial products (Zend Guard, ionCube, phpShield, SourceGuardian) can be decrypted if someone really, really wanted to. No tool or technique in any language can make absolutely secure obfuscation, there is no "unhackable" system. Everything boils down to effort over time.
If it isn't important enough to bother doing it right, then you're probably wasting your time on the issue. Further, if it is absolutely vital that some information or code remain private, you should simply not put it out into the public purview.
[edited for clarity]
Ultimately, you need to trust the encrypting party. If you don't trust them (apparently you don't), then don't give them access to your server (through executing their decryption code/your obfuscated code, possibly with who-knows-what else inside). Simple as that, albeit possibly inconvenient.
php is usually running on the server where the users have no access to the code(neither source nor any other representation) anyways. No reason to obfuscate it there.
Obfuscating php is only useful in the rare cases where you give the php code to clients. For example if you want clients to be able to run their own server but not give them full access to the code.
So, it looks like all it does is obfuscate the code so it's not human-readable. The only way this would really be useful is to prevent lazy people who have access to the code from reading it. However, it uses simple functions to encode/decode, so it would be trivially easy for someone to decode it if they have access.
Which brings me to my point... PHP security works by not allowing anyone to have access to the source file. If someone who shouldn't have access gets it, then this "encoding" thing isn't going to do you any good.
The OP mentioned an interest in protecting database connection details, and it should be kept in mind that no matter what protection system is used for the code itself, the PHP engine and component libraries being opensource sets some absolute limits on what can be achieved. If MySQL connection details, for example, are hidden in a script then these details could be trivially revealed without going near the PHP scripts themselves simply by running the scripts with a PHP build that had slight modifications to the MySQL library or the associated PHP module wrapper. Even hiding the details in a C module as suggested by Chris L. would afford no extra protection in this case. Good protection can certainly be given to source code with compiled code systems such as ionCube and Zend, but wherever data hits routines in the PHP core then it can be exposed.
Obviously for any online service where you may be sending sensitive details, you should use due diligence and make best efforts to ensure that it has a good pedigree. Apart from anything else, not having a working https URL for the site the OP questioned should immediately warn that it's a no-no, and not just for the lack of connection encryption but showing that they are not offering a service that they consider to be serious.
