在Java Web应用程序中，您将密钥存储在何处？

密码学是一种广泛采用的确保机密性的技术。不考虑实现缺陷，它只有一个关键点：密钥存储。如果密钥被盗，整个系统将受到威胁

编辑：

让我具体说明问题的来龙去脉：

这里介绍一个JavaWeb应用程序

更具体地说，它用于spring框架版本3

spring security 3.1用于保护应用程序

mysql5数据库可用

应用服务器是tomcat6或tomcat7

服务器计算机不在我的控制下

也许问题可以集中在这个场景上，但正如所指出的，密钥存储的问题与所采用的技术是横向的。然而，有些库可能会提供一些独特的功能，以某种方式促进这项工作。 一个明确的观点是，必须在安全性和做实际事情的需要之间找到一个折衷方案。要完成分析，很明显，所需的安全级别取决于要保护的信息的价值。为了保密客户的鞋码，我们会改变主意，实施超级安全策略（需要付出很多努力），这是毫无意义的

在这里，我必须确保电子邮件密码（将存储在数据库中）。我认为这个信息是关键的。< /P> 我在这里寻找的是经过合理努力的最佳解决方案

所以问题很清楚：您将这些信息存储在哪里？

您是否将其存储在数据库中？所以它应该被加密，这需要另一个密钥（第二个密钥存储在哪里？）

您是否将其存储在

.war

包中？如何防止未经授权访问源

你采取了不同的策略吗

您的战略动机将受到赞赏。

---

谢谢你

不管你需要什么，你总是需要把秘密钥匙存放在某个地方。即使您决定（这是愚蠢的）手动提供密钥，该密钥仍驻留在内存中，有人可以找到它

存放地点取决于您的选择。但是，它不应该是纯文本。所以，若您在数据库中存储了一个密钥，那个么在应用程序中使用硬编码的辅助密钥。因此，如果入侵者只能访问数据库，则加密的主密钥受到保护

我会选择应用程序配置，将辅助密钥存储在容器中。这样，只有您的应用程序才能访问此属性。因此，攻击者必须控制您的应用程序或容器才能访问该密钥

因此，假设以下情况：

您的应用程序被黑客攻击：攻击者拥有与您相同的权限。您可以尝试使用API获取敏感信息，而无需使用加密。你的代码将为他们做这件事。下一个选项：她可以尝试获取您的war文件或类文件，并对它们进行反编译以找出硬编码密钥，或者了解您使用的加密机制

只有数据库被黑客攻击：使用数据库本身不存在的密钥加密数据应该没问题

让攻击者更难对付。您可以将文件放在文件系统中。如其他答案中所述，向其添加适当的FS权限。但是另外，使用java安全管理器来限制对所有java类的访问，除了真正需要读取它的类。另外，限制对jar和类文件的修改也是一个好主意

---

锁越多，你就越安全。与标准门锁一样。锁应该来自不同的供应商，并且具有不同的机制。但是到头来，技术娴熟的窃贼还是会介入进来。

即使这与JavaWeb应用程序没有任何关系，我还是冒昧地写了一个答案：我认为问题只存在于所有平台的微小差异中

基本上，密钥存储有3个候选项，您提到的前2个：

• DB
• 应用程序（“硬编码”）
• 运行WebApp的服务器上的其他位置，通常是一个文件

我完全同意，你已经指出了前两项的弱点，因此无需重复

这也是我使用第三个候选人的动机。理由是：

• 同一个应用程序的不同实例可以很容易地拥有不同的密钥，因此一个应用程序的折衷方案不会自动传播到所有其他应用程序
• 如果服务器受到某种程度的破坏，允许攻击者读取任何文件，那么游戏就结束了：你无法阻止他读取应用程序二进制文件或数据库
• web服务器上的文件系统安全性是一个非常容易理解的主题
• 与应用程序或数据库入侵相比，允许完全文件系统访问的入侵在统计上要少得多

---

文件系统正常，请选择用户权限并在war上使用“授予权限”。存在许多安全漏洞，只能访问数据库或战争内容

另请参见“我在哪里安全地存储源代码可见的系统的密钥？”和“密码保护密钥的最佳实践”，这在很大程度上取决于用例和环境，因此无法以任何有意义的方式回答；买一本关于密钥管理的书。好的，你说在服务器机器的文件系统中创建一个文件，然后在那里用明文写密码。当然，我必须对该文件设置严格的权限（例如，只有“应用程序用户”才能读取该文件）。一个常见的场景是服务器机器不在您的控制之下。管理员用户无论如何都可以做任何事情。可能使用客户端密钥对带有密钥的文件进行加密。但这将意味着一个更复杂的体系结构，它并不总是可用的。好的，我们