首先要做的是将用户密码从中分离出来。您必须解密并重新加密他们的所有文件。可能还有其他方法可以解决此问题,例如仅允许新文件使用此系统。但这是非常特定于用例的,例如您将他们的文件保留多长时间,他们的上交量是多少等等。
无论如何,这是一种方法:
- 使用您生成的密码加密他们提交的文件。
- 将此密码存储在另一个文件中,我们暂时将其命名为
key.txt。使用用户密码加密此文件。
- 当用户登录时(如果他们没有存储)获取他们的密码,解密
key.txt 并获得生成的密码。
- 现在您可以将生成的密码保存在您想要的任何位置,而不会影响用户帐户。
- 他们所看到的(最终用户体验)看起来就像他们总是去下载文件、输入密码并获取文件一样。他们永远不会知道你这样做了,这对他们来说很好。
所以问题一解决了。
现在我们应该把它存储在哪里?
您可以简单地将其存储在数据库中的服务器上。这取决于数据的机密性以及服务器的安全性。您最终要对他人数据的安全负责,至少这样您可以控制它。
用这些字段制作一个表格
user_id | ip | password | last_access
当用户去下载文件时,检查他们的最后访问时间和IP地址以使密码无效并让他们刷新它。这非常容易设置并且完全在您的控制之下。如果您保存加密密钥,它总会存在一定程度的漏洞,至少这样它就在您的控制之下。
即使您不想将其存储在数据库中,这里最大的缺点是如果有人持有该表,但如果他们这样做并且您存储重要数据,您可能已经有很多问题了。
至少使用第一部分,因为这解决了将其与实际帐户密码绑定的大问题。即使黑客从客户端获取文件密码(被盗的 cookie 等),因为它是独立的,仅此一项不会让他们像帐户密码那样登录到您的网站。我在这里假设,用户必须登录才能进入下载部分。对两者使用相同的密码使他们可以访问获取此数据的方法和下载数据的方法。
需要明确的是,它们是关于将其存储在客户端的一个论点。然后,如果您的网站遭到入侵,那么有人获得密码的机会就会减少,因为它(取决于您如何操作)仅存在于客户端和服务器等的内存中。这将责任推给他们。
非对称加密
您也可以使用非对称加密。目前它看起来你正在使用 AES,这很好,但它是一个对称密钥块密码。基本上有三种常见的“加密”形式(白话):
散列(实际上不是加密) - md5、sha1、sha256 - 这些是一种方式,无法解码。它们具有固定的长度,并且总是加密到相同的东西。对于文件校验和(用于验证文件的内容)、块链、密码或其他任何需要比较两个“加密”值的东西,这种情况很常见。
对称 - AES、3DES、Blowfish、Twofish - 任何您需要加密和解密的东西。同一个键可以同时做这两个。通常,由于 IV,它们每次都会将相同的东西加密为不同的值。
非对称 - SSL、DSA、RSA、PGP,用于加密货币钱包、TLS 等。有了这些,您有 2 个密钥,一个公共密钥和一个私有密钥。密钥不能解密自己的加密数据,只有另一个密钥可以。因此,如果您在服务器上有一个密钥,而客户端有另一个密钥。您可以使用您的密钥加密他们的文件(只能通过他们的密钥解密),并且您不必担心有人得到您的密钥,因为它不允许他们解密文件。您可以将一个密钥提供给客户端,客户端可以使用该密钥来解密您加密的数据(即使没有您的密钥)。每次您使用它们时,它们也会加密为不同的“Stuff”。
因此,您可以看到不对称形式在两方(或更多)方系统中使用时具有一些优势。它还有一个好处是您不需要他们的密钥来加密文件。你所需要的只是你的一部分。因此,例如,如果您为他们生成数据并且不想加密,然后让他们使用相同的系统对其进行解密,那么您可以毫无问题地做到这一点。这可能会消除一个步骤,因为您需要询问他们,或者在您想要加密某些东西时随时跟踪他们的对称性。在这里,您只需要密钥对的一部分。
实际上(在服务器上)实现并不难,只是更难理解它的作用。这就是为什么我决定添加这个的原因,如果没有这些知识(你可能知道也可能不知道),很难使用这些术语并使它们有意义。如果您使用非对称加密,对您(如果您这么称呼它)来说唯一真正的缺点是,如果客户端丢失了他们的密钥,您将无法解密文件。所以我会确保他们知道将它们备份在一个安全的地方。当您丢失非对称加密的加密货币钱包时,这与您在新闻中看到的问题相同
正如我所说,我的大部分知识都与加密和处理服务器上的数据有关。所以我不确定如何将其与“客户体验”联系起来。例如,我确实知道如何使用 RSA 密钥进行 SSH 等无密码登录。这有点像,但不完全一样。
希望对你有帮助!