如何将加密密钥安全地存储在 php 代码文件中
我有一个网站，用户向其提交敏感数据，然后 php 脚本使用 rijndael 256 加密这些敏感数据并将其存储在 mysql 数据库中，
问题是我想将密钥存储在只能由 php 访问的安全位置脚本并且不被任何其他人看到
I have a website that users submit sensitive data to it then a php script encrypts these sensitive data using rijndael 256 and store it in mysql database
the problem is that I want to store the key in a secure place that can be accessed only by the php script and not to be seen by any other one
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
取决于您需要的数据安全性有多高。您可以考虑为每个用户使用不同的安全密钥，方法是对标识该特定客户的数据进行加密并将其附加到 256 位加密密钥上。但更好的方法是将密钥分开并在整个密钥中插入加密数据。使得破译变得更加复杂。这意味着，如果程序员有权访问密钥，那么程序员就无法简单地解密每个人的数据，而无需访问客户加密的数据，这对于每个用户来说都是不同的。
是的，程序员确实仍然可以将密钥回显到屏幕上，但他们还需要为他们想要解密数据的每个客户提供客户加密数据。
如果适用，您还可以考虑使用公钥和私钥加密。客户/用户可以生成自己的密钥。客户将公钥放入网站上的表格中，该表格存储在数据库中，然后客户/用户将拥有私钥来解密数据。您使用公钥来加密数据。这意味着每个用户/客户都有自己的一组密钥。私钥甚至可以放在钥匙卡上并连接到计算机以验证访问。
更多信息@http://en.wikipedia.org/wiki/Public-key_cryptography
Depends on how high a security you need for the data. You could consider having a different security key for each user, by possibly encrypting the data that identifies that particular customer and attaching it onto the 256-bit encrypted key. But better still would be split the key up and insert that encrypted data throughout the key. Makes it more complex to decipher. This would mean if a programmer has access to the key the programmer can't simply decrypt everyones data without having access to the customer encrypted data as well which would be different for every user.
And yes it is true that the programmer can still echo the key out to the screen but they would ALSO need the customer encrypted data for each customer they want to decrypt the data of.
You could also consider Public and Private Key Encryption instead if applicable. The customer/user could generate their own keys. Customer places the public key into a form on the website which gets stored in the database, then the customer/user would have the private key to decrypt the data. You use the public key to encrypt the data. This would mean each user/customer would have their own set of keys. The Private key could possibly be even placed on a keycard and hooked to the computer to verify access.
More information @ http://en.wikipedia.org/wiki/Public-key_cryptography
一种替代方法是让 PHP 脚本调用可以访问密钥的外部脚本（不一定是另一个 PHP 脚本；可以是任何脚本）。只要没有人具有对外部脚本的写访问权限，或者如果将密钥硬编码到外部脚本中则没有人对其具有读访问权限，那么它应该相对安全。如果将密钥存储在单独的文件中，则该文件只能由外部脚本的所有者读取/写入。
One alternative would be to have the PHP script call an external script (doesn't necessarily have to be another PHP script; it could be anything) that would have access to the key. As long as no one has write access to the external script, or read access to it if you hard-code the key into it, then it should be relatively secure. If you store the key in a separate file, that file needs to be readable/writable only by the owner of the external script.
您可以使用证书进行加密/解密，并让服务器在启动时请求证书的密码。
好处是您的密钥仅存在于内存中，并且对于每个安装/服务器都可以不同。
然而，这种方法相当痛苦，并且通常仅在您拥有自己的系统管理员/不依赖第三方托管提供商时才有效。
中间解决方案，用于在数据库中为每个部分/用户/客户端生成加密密钥，并使用每个客户端密钥加密敏感数据。这些每个客户端的密钥使用主密钥进行加密并存储在数据库中，而主密钥则以最小的权限存储在磁盘上的某个位置。
当您的服务器完全受到攻击时，这不会保护您的安全，但确实会限制数据泄漏/部分受到攻击等情况下的风险。
如果问题是您不信任 a) 程序员或 b) 系统管理员，那么您就不走运了。
You could encrypt/decrypt with certificates and have the server request a password for the certificate upon bootup.
The good thing is that your key is only in memory and can be different for every installation/server.
However, this method is quite a pain and generally only works when you have your own system administrators/are not dependent on a third-party hosting provider.
The intermediate solution to generate an encryption key per section/user/client in your database and encrypt the sensitive data with this per client key. These per-client keys are encrypted with a master key and stored in your database, while the master-key is stored somewhere in on disk with minimal priviliges.
This will not safe you when your server gets fully compromised, but does limit the risk in case of -for example- a data-leak/partial compromise.
If the problem is you don't trust a) the programmer or b) the system administrator, you are out of luck.