php - 加密存储的图像

Question

我正在准备一个需要以加密格式存储图像的项目。图像将在0.5mb至5mb之间，并且必须保持原始质量。

我当时在考虑使用base64对其进行编码，但是随后我将需要使用某种方式对其进行加密（SHA1？），并将其另存为文件在服务器上。

有人可以建议我吗？可以将加密的图像存储在哪种文件中？

提前致谢

Answer 1

该操作并不简单；您不仅需要加密数据，还需要使其安全以防服务器上的盗窃或入侵。您还需要考虑如果需要更改密钥会发生什么情况。

要加密图像，最好的选择可能是使用对称算法的mcrypt。有一些有关如何执行此操作的教程。请参阅What is the best way to encrypt files in AES-256 with PHP?。

您需要做的就是提供图像并即时对其进行解密，而无需将其存储在明文中。

现在的问题是在哪里保存密码。最好的整体解决方案是为每个用户拥有一个秘密的加密密钥，该密钥是在用户应征时随机生成的；密钥本身使用用户密码进行非对称加密。您可以使用phpseclib在RSA中执行此操作。相同的加密密钥也与管理密码不对称地存储。

因此，工作流程为：


用户登录（并提供密码）
系统将密码哈希与存储的哈希进行比较，并授予访问权限（您将使用诸如bcrypt之类的方法：请参见Is there a bruteforce-proof hashing algorithm?）
系统还会解码加密字符串并将其存储在临时会话中（会话的持久性可能是一个难以解决的问题！）
现在该用户可以访问该用户的所有图像


加密图像：
-如果用户上传图像，则在上传时，会话中的加密密钥可用。用它 ：-）
-如果以其他方式上传图像，则会在数据库中设置“已加密/仍要加密”标志，并尽快（管理员登录/用户登录）执行所有待处理的加密操作。

然后将图像存储为加密文件（“ 001823040.bin”）。除了在数据库中没有引用之外，没有引用。并且不认识用户（因此加密密钥），该图像无法恢复。

要提供图像，您只需将标题设置为图像类型，然后开始解码文件并将其以明文形式输出到用户的浏览器。

从攻击者的角度来看，仅拥有映像是没有用的，因为它们是加密的。用户数据库无用，因为加密密钥本身已加密。窃取或暴力破解一个用户的密码只能获得对该用户的加密密钥的访问权限，而该加密密钥不同于其他所有用户的加密密钥，然后还有查找属于该用户的图像的任务。

如果需要更改用户密码，仍然可以使用管理密码来恢复加密密钥，并使用用户的新密码非对称地对其重新加密。无法自动完成此操作，因为这意味着将现在非常重要的管理员密码存储在系统上的明文中。因此，所有忘记密码的用户都将排成一排，早晨，管理员会收到通知“有75个人在等待密码恢复”，提供密码并将其全部解锁。

这很尴尬，但是所有其他解决方案都不幸地依赖于以纯文本格式在本地可用的密码，因为安全性受到威胁会导致系统处于打开状态。

（您有时可以通过设置第二台小型的非常有限的服务器来解决该限制，因此也就不那么脆弱了，它可以充当加密托管服务；但是维护起来要复杂得多。

多个用户/密码方案

您在一个表中有资源A，并且有几个有权访问该资源的用户U1，U2，... Un。这意味着用户U1必须能够访问资源A的解密密钥。

您可以通过存储UserAccessToResource表来做到这一点：

user_id         -- the user ID
resource_id     -- the resource ID
encryption      -- resource decryption key, encrypted with the user's encryption **key**

要授予对用户U1和资源A的访问权限，您必须自己有权访问资源A和U1的加密密钥。那是：


管理员访问“用户”表并恢复UserKeyEncryptedWithAdminKey。
作为管理员，他可以解密UserKey。
他以相同的方式访问ResourceTable [A] .ResourceKeyEncryptedWithAdminKey
他使用UserKey加密ResourceKey并将其存储到UserAccessToResource


用户U5过来并且可以快速验证UserAccessToResource表中是否存在（5、42，??），因此他知道他可以访问该资源。检索行，并解密ResourceKey。现在，他可以访问Resource [42]并使用ResourceKey解密（但没有其他资源，因为它们具有不同且随机的ResourceKey）。

在所有这些情况下，前端永远都无法访问（除非存在编程错误）ResourceKey（或UserKey）的实际值。该API类似于 DecryptResource(UserId, UserPass, ResourceId)，并返回解密的资源。

当然，UserAccessToResource可以包含任意数量的用户或资源-数量很多。对于每个密钥，必须存储一个加密密钥（例如，对于AES条目，为32个十六进制字节）。

密码丢失的情况

不幸的是，该操作无法自动完成。用户发送了一个请求，但是直到并且除非管理员登录，否则他的密钥是不可访问的。因此，他必须等待。

管理员登录后，系统便可以访问PasswordRecovery表并查找用户的不完整记录。它访问用户表并检索UserKeyEncryptedWithAdminKey。

现在，它会生成一个随机密钥，并使用该随机密钥对UserKey进行加密，从而完成PasswordRecovery表中的记录。另一列包含用相同的随机密钥加密的“ Squeamish Ossifrage”一词。他向用户123发送安全电子邮件，并提供随机密钥。

用户123将随机密钥提供给系统。管理员不再登录，但是系统可以检查解密后的第二个表字段确实是“ Squeamish Ossifrage”。然后，假定第一个字段是解密的UserKey。系统从User123请求新密码，并将新的UserKeyEncryptedWithUserPass存储到Users表中，从而清除PasswordRecovery中的条目。仅更新了一条记录。用户123拥有的所有资源密钥均使用用户123的密钥进行加密，该密钥没有更改，仍然是由管理员创建帐户时随机生成的密钥。

下次登录时，用户将提供密码并解锁系统。