【问题标题】:Only require password once to decrypt files at different times?只需要密码一次就可以在不同时间解密文件?
【发布时间】:2019-03-14 01:52:36
【问题描述】:

用户的内容已加密,但需要解密。有多个文件需要解密才能查看,肯定不会同时查看。

我目前正在通过使用用户的明文密码来加密随机生成的密钥,从而加密用户的数据。在执行任何操作之前,密码通常会经过哈希处理和验证。我正在使用 PHP 的 aes-128-gcm openssl_encrypt() 函数。

我当前的系统每次用户想要读取文件时都需要密码。

我曾考虑一次性解密所有内容,但这并不能很好地扩展。我也考虑过将用户的密钥存储为 cookie,但我担心安全性。

有没有标准的方法来做到这一点? 谢谢!

【问题讨论】:

    标签: php encryption


    【解决方案1】:

    他们绝对不会同时被观看

    这里最安全的答案不是每次都要求输入密码吗?我会假设(尽管我确定这不是您正在寻找的答案)每次简单地询问密码可能是最好的解决方案。 虽然这对用户来说可能很乏味,但我也认为它会带来一些安全感 - 因为它不像登录那么简单(因为文件是加密的)。

    从我的角度来看,我认为加密文件不应该被大规模解密?

    抱歉,我知道这不是您要寻找的答案 - 但如果您有更多关于您的动机的信息,也许可以找到更合理的解决方案?

    【讨论】:

    • 用户登录查看他们的文件。从用户的角度来看,他们已经登录了,不需要每次都输入密码。但我确实同意解密所有信息并不是最好的解决方案,这就是为什么我正在考虑使用 cookie。
    【解决方案2】:

    不要在服务器端进行解密 - 在客户端进行。将用户密码保存在自己设备的内存中是安全的。

    【讨论】:

    • 关于如何做到这一点的任何建议。我只是好奇我所做的大部分工作都在服务器上,所以我对这个主题并不熟悉,因为它与客户端有关。我同意尽可能将其保存在内存中可能是最安全的存储方式。
    • 我想重申@ArtisticPhoenix 提出的问题。我同意在客户端进行解密可能是我这种情况的最佳解决方案,但我一直无法找到它的 js 库。我正在权衡在服务器端执行此操作的可能性,但我只是不知道服务器和客户端之间的 https 连接有多安全,对此有何见解?
    • HTTPS/TLS 非常安全,除了偶尔的 HeartBleed(错误/漏洞)。它可能与您通过网络到达客户端一样安全的传输层,这就是它如此广泛使用的原因。 TLS 使用非对称加密,即一对公钥私钥。每个密钥可以加密但不能解密自己的东西。因此,公钥可以从私钥解密内容,而私钥可以从公钥解密内容,但不能解密自己的内容。我想建议您也将其作为加密文件的一种方式。 Wikipedia
    • 如果您使用非对称加密,对您(如果您这么称呼它)来说唯一真正的缺点是,如果客户端丢失了他们的密钥,您将无法解密文件。所以我会确保他们知道将它们备份在一个安全的地方。当涉及丢失非对称加密的加密货币钱包时,您在新闻中看到的问题与您在新闻中看到的问题相同。如。 Access to Quadriga CX’s digital “wallets” -- an application that stores the keys to send and receive cryptocurrencies -- appears to have been lost with the passing of Quadriga CX Chief Executive Officer in India = 200Mil
    【解决方案3】:

    首先要做的是将用户密码从中分离出来。您必须解密并重新加密他们的所有文件。可能还有其他方法可以解决此问题,例如仅允许新文件使用此系统。但这是非常特定于用例的,例如您将他们的文件保留多长时间,他们的上交量是多少等等。

    无论如何,这是一种方法:

    1. 使用您生成的密码加密他们提交的文件。
    2. 将此密码存储在另一个文件中,我们暂时将其命名为key.txt。使用用户密码加密此文件。
    3. 当用户登录时(如果他们没有存储)获取他们的密码,解密key.txt 并获得生成的密码。
    4. 现在您可以将生成的密码保存在您想要的任何位置,而不会影响用户帐户。
    5. 他们所看到的(最终用户体验)看起来就像他们总是去下载文件、输入密码并获取文件一样。他们永远不会知道你这样做了,这对他们来说很好。

    所以问题一解决了。

    现在我们应该把它存储在哪里?

    您可以简单地将其存储在数据库中的服务器上。这取决于数据的机密性以及服务器的安全性。您最终要对他人数据的安全负责,至少这样您可以控制它。

    用这些字段制作一个表格

      user_id | ip | password | last_access
    

    当用户去下载文件时,检查他们的最后访问时间和IP地址以使密码无效并让他们刷新它。这非常容易设置并且完全在您的控制之下。如果您保存加密密钥,它总会存在一定程度的漏洞,至少这样它就在您的控制之下。

    即使您不想将其存储在数据库中,这里最大的缺点是如果有人持有该表,但如果他们这样做并且您存储重要数据,您可能已经有很多问题了。

    至少使用第一部分,因为这解决了将其与实际帐户密码绑定的大问题。即使黑客从客户端获取文件密码(被盗的 cookie 等),因为它是独立的,仅此一项不会让他们像帐户密码那样登录到您的网站。我在这里假设,用户必须登录才能进入下载部分。对两者使用相同的密码使他们可以访问获取此数据的方法和下载数据的方法。

    需要明确的是,它们是关于将其存储在客户端的一个论点。然后,如果您的网站遭到入侵,那么有人获得密码的机会就会减少,因为它(取决于您如何操作)仅存在于客户端和服务器等的内存中。这将责任推给他们。

    非对称加密

    您也可以使用非对称加密。目前它看起来你正在使用 AES,这很好,但它是一个对称密钥块密码。基本上有三种常见的“加密”形式(白话):

    1. 散列(实际上不是加密) - md5sha1sha256 - 这些是一种方式,无法解码。它们具有固定的长度,并且总是加密到相同的东西。对于文件校验和(用于验证文件的内容)、块链、密码或其他任何需要比较两个“加密”值的东西,这种情况很常见。

    2. 对称 - AES3DESBlowfishTwofish - 任何您需要加密和解密的东西。同一个键可以同时做这两个。通常,由于 IV,它们每次都会将相同的东西加密为不同的值。

    3. 非对称 - SSLDSARSAPGP,用于加密货币钱包、TLS 等。有了这些,您有 2 个密钥,一个公共密钥和一个私有密钥。密钥不能解密自己的加密数据,只有另一个密钥可以。因此,如果您在服务器上有一个密钥,而客户端有另一个密钥。您可以使用您的密钥加密他们的文件(只能通过他们的密钥解密),并且您不必担心有人得到您的密钥,因为它不允许他们解密文件。您可以将一个密钥提供给客户端,客户端可以使用该密钥来解密您加密的数据(即使没有您的密钥)。每次您使用它们时,它们也会加密为不同的“Stuff”。

    因此,您可以看到不对称形式在两方(或更多)方系统中使用时具有一些优势。它还有一个好处是您不需要他们的密钥来加密文件。你所需要的只是你的一部分。因此,例如,如果您为他们生成数据并且不想加密,然后让他们使用相同的系统对其进行解密,那么您可以毫无问题地做到这一点。这可能会消除一个步骤,因为您需要询问他们,或者在您想要加密某些东西时随时跟踪他们的对称性。在这里,您只需要密钥对的一部分。

    实际上(在服务器上)实现并不难,只是更难理解它的作用。这就是为什么我决定添加这个的原因,如果没有这些知识(你可能知道也可能不知道),很难使用这些术语并使它们有意义。如果您使用非对称加密,对您(如果您这么称呼它)来说唯一真正的缺点是,如果客户端丢失了他们的密钥,您将无法解密文件。所以我会确保他们知道将它们备份在一个安全的地方。当您丢失非对称加密的加密货币钱包时,这与您在新闻中看到的问题相同

    正如我所说,我的大部分知识都与加密和处理服务器上的数据有关。所以我不确定如何将其与“客户体验”联系起来。例如,我确实知道如何使用 RSA 密钥进行 SSH 等无密码登录。这有点像,但不完全一样。

    希望对你有帮助!

    【讨论】:

      猜你喜欢
      • 2018-09-28
      • 1970-01-01
      • 2016-05-17
      • 2015-05-21
      • 2012-07-28
      • 1970-01-01
      • 1970-01-01
      • 2020-11-19
      • 2021-10-01
      相关资源
      最近更新 更多