你在哪里将密钥存储在Java Web应用程序中？

密码术是一种被广泛采用的技术来确保机密性。不考虑执行缺陷，它有一个关键点：密钥存储。如果秘密密钥被盗，整个系统将受到威胁。你在哪里将密钥存储在Java Web应用程序中？

编辑：

让我指定的范围内，使这个问题不太广：

这里Java Web应用程序是针对
更具体地说，它使用了Spring框架的版本3
spring security 3.1用于保护应用程序
mysql5数据库可用
应用程序服务器的tomcat6或tomcat7
服务器机器是我的控制之下没有

或许这些问题可以集中在这种情况下，但正如指出的那样，密钥的问题存储横向于采用的技术。然而，一些图书馆可能提供可以以某种方式促进这项工作的独特功能。明确的一点是，必须在安全和需要做实际事情之间找到权衡。为了完成分析，显然所需的安全级别取决于要保护的信息的价值。为了保护顾客的鞋子尺寸，推翻超级安全战略（需要付出很多努力）是毫无意义的。

在这里，我必须确保电子邮件密码（将存储在数据库中）。我认为这个信息平均至关重要。

我在这里寻找什么，是合理努力的最佳解决方案。

所以问题很明确：你会在哪里存储这些信息？

你把它存储在数据库中吗？所以它应该被加密，这需要另一个密钥（并且你在哪里存储这个第二个密钥？）
你是否将它存储在.war包内？你如何防止未经授权的访问来源？
你采用不同的策略？

您的战略动机将不胜感激。谢谢

来源

2012-12-21 MaVVamaldo

另请参见“我可以在哪里安全地存储源可见系统的密钥？” http://security.stackexchange.com/questions/5994/where-do-i-securely-store-the-key-for-a-system-where-the-source-is-visible，以及“密码的最佳实践 - 保护密钥“http://security.stackexchange.com/questions/20076/best-practice-for-password-protecting-a-secret-key， –

这非常依赖于用例和环境，这是不可能以任何有意义的方式回答;改为购买关键管理书籍。 –

我自由地写了一个答案，即使这与一个Java Web应用程序没有任何关系：我认为问题存在与所有平台只有很小的差异。

基本上有存储密钥3名候选人，其中第2的你所提到的：

的DB
应用程序（“硬编码”）
别的地方的服务器上，运行在WebApp，最常见的是文件

你已经把你的手指在第一2的弱点，因此无需再重复，我完全同意。

这也是我使用第三名候选人的动机。原因是这样的：

不同的情况下，就可以轻松拥有不同的密钥，所以一个的妥协不会自动如果服务器在某种程度上受到影响波及到所有其他
，允许攻击者阅读任何文件，这是游戏无论如何：你将无法阻止他阅读应用程序二进制文件或数据库
Web服务器上的文件系统安全性是一个很好理解的主题
Break允许完整的文件系统访问在统计上比应用程序或数据库的闯入少得多

来源

2012-12-21 13:42:55

ok，所以你说在服务器机器的文件系统中创建一个文件并以明文形式写入密码。当然，我必须对该文件设置严格的权限（例如，只有“应用程序用户”可以读取它）。一种常见的情况是服务器不受您控制的情况。无论如何，管理员用户可以做任何事情。也许带密钥的文件可能使用客户端密钥加密。但这意味着更复杂的架构并不总是可用的。好吧，我们不得不相信提供者。 – MaVVamaldo

将密钥放入文件（或者像@AleksanderGralak所建议的容器）可以在没有额外步骤的情况下完成，例如使用硬编码密钥对密钥进行加密。流氓管理员与成功的根级别攻击者是一样的：没有任何东西对他来说是安全的 –

使用我可以看到的文件有两个问题：1）如果您的应用程序需要保持此文件重复（或更多）并同步变得足够大，需要多个负载均衡的实例。 2）如果你有大量的用户，那么搜索文件可能成为一种负担。我不认为自己是这方面的专家，但这是我刚才为自己弄清楚自己的一些想法。但这是我见过的为我提供其他人正在寻找或制作相同解决方案的线索的少数帖子之一。 – BillR

不管你总是需要在什么地方存储密钥。即使你决定（这是愚蠢的）你手动提供密钥，那么密钥驻留在内存中，并且有人可以找到它。

你在哪里存放取决于你的选择。但它不应该是纯文本。因此，如果您将密钥存储在数据库中，则应用程序中使用硬编码的辅助密钥。因此，如果入侵者只能访问数据库，那么加密的主键就会受到保护。

我会去应用程序配置存储在容器中的二级键。这样只有你的应用程序才能访问这个属性。因此，攻击者必须控制应用程序或容器才能访问该密钥。

因此，假设以下情况：

您的应用程序遭受过黑客攻击：攻击者具有相同的权限，你有。你可以尝试使用你的API来获取敏感信息，而不用使用加密进行播放。你的代码会为他们做。下一个选项：她可以尝试获取您的战争文件或类文件并反编译它们以找出硬编码的密钥，或了解您使用的加密机制。
只有数据库被黑客入侵：你应该没有数据加密数据库本身的密钥。

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

你拥有的锁越多，就越安全。与标准门锁一样。锁应该来自不同的供应商和不同的机制。但最后，熟练的窃贼将进入无论如何。

来源

2012-12-21 13:33:12

@Alexsander：你有什么教程可以在java中实现吗？如何在容器中存储secondy密钥以及secondry和promary密钥如何在db中加密数据。 – anand

另外我们如何限制java中不同用户的文件系统权限？ – anand

@ Alien01只是为了澄清。加密整个数据库不在这个问题的范围之内，据我所知，这是更实验的想法，然后是真实的事情。所以在我们的情况下，秘密就是电子邮件的密码。所以你存储加密密钥在应用程序上下文中： http://stackoverflow.com/questions/372686/how-can-i-specify-system-properties-in-tomcat-configuration-on-startup 然后你使用对称加密加密密码。现在您可以从数据库中检索密码并将其解密并用于访问SMTP服务器。 –

文件系统没问题，请选择用户权限并在战争中使用授予权限。有很多安全漏洞只能访问数据库或战争内容

来源

2012-12-21 13:58:29 chro

你在哪里将密钥存储在Java Web应用程序中？

回答

相关问题