Java Web应用程序上的加密/安全

我们有一个用Java编写的web应用程序，它将数据存储到PostgreSQL数据库中

我们想要加密数据库中的一些字段，以及一些上传的文档。然而，这些都需要双向加密（即，我们需要能够解密它们），并且解密需要相当快

然而，我们无法想出一种“安全”的方法来实际加密/解密数据。因为这是一个web应用程序，并且没有客户端，所以所有加密密钥都将存储在web服务器（明文或我们的实际代码）或数据库服务器上

---

关于如何做到这一点的任何其他想法至少是适度的。。。安全吗？

不，没有。如果您的业务层必须访问原始（未加密）数据，那么任何可以攻击您的业务层的人（即，在应用程序代码中存储的某个关键字或应用程序可读的文件中偷看）也可以访问数据。另见此

---

使用应用程序可读的解码密钥实现一些加密只会为您提供轻微的保护，使您免受偶然的数据间谍和某些用户角色或情况（例如：可以读取数据库但不能读取webapp的DBA；或窃取数据库转储的人等）。但仅此而已。

AES是一个完善的对称加密标准，JDK内置了对它的支持，因此我建议您使用它

现在，您完全正确地认识到密钥需要以应用程序可以访问的方式存储。但是，与将密钥存储在代码或文件中不同，您可以将密钥“分割”到不同的物理位置，以使内部人员更难破解您的加密。例如：

在开发时，生成一个新的 键和“硬编码”将其输入到您的 节目。这把钥匙叫A

在安装时，生成一个 第二把钥匙。现在就叫这把钥匙B 使用密钥A加密密钥B并存储 中的加密版本 文件系统。使文件可读 仅适用于 服务器运行

对于您加密的每个值（例如， 每个信用卡号），生成一个 第三把钥匙。调用此键C。使用此键 C来加密该值。然后加密 键C和键B并存储 它的加密版本在 数据库（您可以使用单独的 字段在同一个表中。）

要解密，您需要从数据库读取加密密钥C，从文件系统读取加密密钥B。使用密钥A解密密钥B，使用密钥B解密密钥C。然后使用密钥C解密值

---

这一切给你带来了什么？我们的想法是将部分秘密传播到几个不同的地方，最好由不同的人群控制。任何想要破解加密值的人都需要访问所有三项：程序代码、文件和数据库。您可以更进一步，在链中添加更多的密钥，但您已经明白了。

您实际上可以使其更加安全

如果您使用带有PKCS11接口的智能令牌，在令牌上生成密钥对，然后在每次应用程序启动时使用手动提供的密码保护对密钥对的访问，则您可以在将来的任何时候通过移除令牌来移除读取数据的能力。在需要容错的情况下，使用一对令牌进行双重加密

这里的重要原则是，私钥可由应用程序使用，但不可由应用程序读取。因此，查看应用程序源代码什么也得不到

此解决方案不会阻止在应用程序运行时访问应用程序的人读取您的数据。但无论如何你都无法阻止它——他们可以在加密之前从内存中读取你的数据

---

如果正确实施，这将安全地保护您免受各种形式的脱机攻击。黑客无法从物理上破解一个好的硬件令牌。在不知道密码的情况下无法提取密钥。无法猜测密码，因为令牌对暴力攻击有硬件限制。因此，恢复数据的唯一方法是窃取令牌和密码，或者强制使用数据加密密钥（可能是2048位RSA证书）。

这是一个非常古老的问题，但我将我的解决方案描述为我自己的解决方案，这对我来说是安全的

在管理员用户创建其帐户期间，我生成随机加密密钥。然后使用管理员密码在AES中对该密钥进行加密并存储在数据库中。管理员密码也是安全的（通过哈希或任何spring密码编码器）。在此阶段，没有人可以访问真正的加密密钥

管理员登录时，会给出普通密码，并与加密的用户密码进行比较。如果它是正确的，它被用来解密加密密码，然后被遗忘。然后在会话中保存加密密码。这是此机制的唯一漏洞-如果有人入侵服务器并进行内存转储，则可以访问密码，但仅限于当前登录的用户，并且永远不会只有应用程序或数据库。我目前正在考虑增加另一个安全级别（例如，通过用户及时登录来加密内存中的密码）。但是，无论如何，即使您要求用户在每个请求中输入密码，您也无法保证它何时被GC从内存中踢出，并且您需要在某个时刻将其保存在内存中

因此，用户会话知道加密密码，然后用于加密和解密。当管理员创建新用户时，在此期间他可以访问未加密的密码-当他为新用户输入新密码时，会创建另一个加密密码副本并保存在数据库中，由该用户密码加密，等等

除了有人入侵正在运行的服务器和du之外，您还看到该机制的任何其他漏洞吗