加密存储的图像

Question

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

我正在考虑使用base64对它们进行编码,但之后我需要使用一些东西来加密它们(SHA1？)并将它们保存为服务器上的文件.

任何人都可以告诉我这个吗？我可以将加密图像存储在哪种文件中？

提前致谢

Answer 1

这项行动并非无足轻重; 您不仅需要加密数据,还需要使其安全,防止在服务器上被盗或闯入; 您还需要考虑如果您需要更改密钥会发生什么.

要加密的图片,你最好的选择可能是这个Mcrypt与对称算法.有几个关于如何做到这一点的教程.请参阅使用PHP加密AES-256文件的最佳方法是什么？.

你需要做的是提供一个图像并在运行中解密它,而不是将它存储在透明图像中.

现在问题是保存密码的位置.最好的整体解决方案是为每个用户提供一个秘密加密密钥,在用户登记时随机生成; 密钥本身是用用户密码不对称加密的.您可以phpseclib在RSA中使用它.相同的加密密钥也使用管理密码非对称地存储.

所以工作流程是:

1. 用户登录(并提供密码)
2. 系统将密码哈希值与存储的哈希值进行比较并授予访问权限(您将使用诸如bcrypt之类的内容:请参阅是否存在强力证明哈希算法？)
3. 系统还解码加密字符串并将其存储在临时会话中(会话的持久性可能是一个需要解决的问题!)
4. 所有用户的图像现在都可供他访问

要加密图像: - 如果用户上传图像,则在上载时加密密钥在会话中可用.使用它:-) - 如果图像是以其他方式上传的,则在数据库中设置"已加密/仍待加密"标志,并尽快(管理员登录/用户登录)所有挂起加密执行操作.

然后将图像存储为加密文件("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的加密密钥.那是:

• 管理员访问Users表并恢复UserKeyEncryptedWithAdminKey.
• 作为管理员,他可以解密UserKey.
• 以同样的方式访问ResourceTable [A] .ResourceKeyEncryptedWithAdminKey
• 他使用UserKey加密ResourceKey并存储到UserAccessToResource中

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

在所有这些中,前端从不访问(禁止编程错误)ResourceKey(或UserKey)的实际值.API类似于DecryptResource(UserId, UserPass, ResourceId) 并返回解密的资源.

当然,UserAccessToResource可能包含任意数量的用户或资源 - 它是多对多的.对于每一个,必须存储加密密钥(例如,对于AES条目,为32个十六进制字节).

丢失密码方案

不幸的是,此操作无法自动完成.用户发送请求,但除非管理员登录,否则无法访问其密钥.因此他必须等待.

当管理员登录时,系统能够访问PasswordRecovery表并找到用户的不完整记录.它访问用户表并检索UserKeyEncryptedWithAdminKey.

它现在生成一个随机密钥,并在PasswordRecovery表中完成记录,其中UserKey使用该一个随机密钥加密.另一列用相同的随机密钥加密"Squeamish Ossifrage".他向用户123发送安全电子邮件,提供随机密钥.

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

下次登录时,用户提供密码并解锁系统.