IonCube 额外的安全层？
我现在正在开发一个 php 项目（Internet Shop），该项目可能会处理本地客户信用卡信息的存储。 所以我在考虑使用 IonCube 加密 php 文件，特别是那些包含设置（加密/解密密钥，IV）的文件 对称加密算法。所以我不确定它是否会增加额外的安全层，因为它似乎是 IonCube 加密的 文件和类似的解决方案可以解密。 谢谢你！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
IonCube 在这里不是合适的解决方案。如果您对包含以下内容的文件进行编码：
恢复秘密值仍然很简单：
所以 IonCube 编码在这里基本上毫无价值。
IonCube is not a suitable solution here. If you encode a file which contains something along the lines of:
It's still trivial to recover the secret value:
So the IonCube encoding is basically worthless here.
ionCube 和 Zend 非常适合代码保护，即使某些反编译服务从编码文件生成可用代码，这通常也不会减少编码和许可证执行的好处，甚至可能在较长时间内增加收入软件提供商的术语。
然而，数据隐藏则完全不同。请记住，PHP 和所有相关的库包装器以及库本身都是开源的，因此很容易修改。通过对 PHP 内部进行简单的更改，可以轻松公开发送到任何 PHP 函数和从任何 PHP 函数返回的数据。想查看MySQL的数据库密码吗？只需修改 mysql_connect() 包装器或底层 MySQL 库并记录详细信息即可。一些编码系统（例如 ionCube）可以加密非 PHP 文件，然后在运行时通过其运行时组件中的闭源例程进行解密，这在某些情况下可能比开源 PHP 例程（例如 mcrypt）提供一些好处。
duskwuff 引用的示例并不完全错误，例如在某些系统中，例如 ionCube，可以通过称为“包含攻击”的机制来保护文件不被非编码文件或由编码器的不同副本编码的文件包含保护”。尽管如此，将敏感数据存储在变量（尤其是全局变量）中是一种糟糕的方法，最好让具有误导性名称的函数返回此类数据，并且除非以特定方式调用，否则可能会执行不同的操作。例如，一个名为 mytime() 的函数会返回时间，除非使用“magic”值调用。
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.
如果您要对文件进行编码/加密，Zend Guard 应该是最好的之一，但正如其他人所说，如果他们可以访问您的文件，那就是您最不担心的事情。
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.