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

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/13991100/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-10-31 14:40:21  来源:igfitidea点击:

Where do you store your secret key in a Java Web Application?

javaweb-applicationsencryption

提问by MaVVamaldo

Cryptography is a widely adopted techonlogy to ensure confidentiality. Not considering implementation flaws, it has a single critical point: the secret key storage. If the secret key is stolen, the whole system will be compromised.

密码学是一种广泛采用的技术,以确保机密性。不考虑实现缺陷,它有一个关键点:密钥存储。如果密钥被盗,整个系统都会受到损害。

EDIT :

编辑 :

let me specify the context to make the question less broad:

让我指定上下文,使问题不那么广泛:

  1. here a java web application is addressed
  2. more specifically it is used the spring framework version 3
  3. spring security 3.1 is used to secure the application
  4. a mysql5 database is available
  5. the application server is tomcat6 or tomcat7
  6. the server machine is notunder my control
  1. 这里解决了一个 java web 应用程序
  2. 更具体地说,它使用的是 spring 框架版本 3
  3. spring security 3.1 用于保护应用程序
  4. mysql5 数据库可用
  5. 应用服务器是 tomcat6 或 tomcat7
  6. 服务器机器不在我的控制之下

Maybe the questions can be focused on this scenario but, as pointed out, the problem of the secret key storage is transversal to the adopted technologies. However some libraries might offer peculiar features that can somehow facilitate the work. A clear point is that a tradeoff has to be found between security and the need to do practical things. To complete the analysis it is obvious that the required security level depends on the value of information to secure. It is senseless to flip our minds to enforce super-secure strategies (demanding a very lot of efforts) to keep secret the shoe size of a customer.

也许问题可以集中在这种情况下,但正如所指出的,密钥存储问题与所采用的技术是横向的。然而,一些库可能提供特殊的功能,可以以某种方式促进工作。一个明确的观点是必须在安全性和做实际事情的需要之间找到一个权衡。要完成分析,很明显所需的安全级别取决于要保护的信息的价值。改变主意以执行超级安全的策略(需要付出很多努力)来保密客户的鞋码是毫无意义的。

Here, I have to secure an email password (that will be stored in a db). I consider this information average critical.

在这里,我必须保护电子邮件密码(将存储在数据库中)。我认为这些信息平均至关重要。

What I'm looking for here, is the best solution with reasonable effort.

我在这里寻找的是经过合理努力的最佳解决方案。

So the question is very clear: where would you store this information?

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

  1. do you store it in a database? So it should be encrypted and this requires another key (and where do you store this second key?)
  2. do you store it inside the .warpackage? How do you prevent unauthorized accesses to the sources?
  3. do you adopt a different strategy?
  1. 你把它存储在数据库中吗?所以它应该被加密,这需要另一个密钥(你把第二个密钥存储在哪里?)
  2. 你把它放在.war包裹里吗?您如何防止未经授权访问源?
  3. 你采取不同的策略吗?

motivations for your strategy will be appreciated. thank you

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

采纳答案by Eugen Rieck

I take the liberty to write an answer even if this doesn't have anything to do with a JavaWeb Application: I think the problem exists in only minor variance with all platforms.

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

Basically there are 3 candidates for key storage, the first 2 of which you mentioned:

基本上有 3 个候选密钥存储,你提到的前两个:

  • The DB
  • The App ("hardcoded")
  • Somewhere else on the server, that runs the WebApp, most often a file
  • 数据库
  • 应用程序(“硬编码”)
  • 服务器上的其他地方,运行 WebApp,通常是一个文件

You already put your finger on the weak points of the first 2, so no need to repeat, I fully agree.

你已经把你的手指放在了前两个的弱点上,所以不用重复了,我完全同意。

This is also the motivation for me to use the third candidate. The reasoning is this:

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

  • Different instances of the same app can easily have different keys, so a compromise of one will not automatically spread to all others
  • If the server is compromised in a way, that allows the attacker to read any file, it is game over anyway: You wouldn't be able to stop him from reading the app binary or the DB
  • File system security on a web server is a quite well-understood subject
  • Break-ins, that allow full filesystem access are statistically much less often, than application or database break-ins
  • 同一应用程序的不同实例很容易拥有不同的密钥,因此其中一个的妥协不会自动传播到所有其他实例
  • 如果服务器以某种方式受到威胁,这允许攻击者读取任何文件,无论如何游戏都结束了:您将无法阻止他读取应用程序二进制文件或数据库
  • Web 服务器上的文件系统安全性是一个很好理解的主题
  • 允许完整文件系统访问的闯入在统计上比应用程序或数据库闯入要少得多

回答by Aleksander Gralak

No matter what you always need to store somewhere the secret key. Even if you decide (which is silly) that you provide key manually, then the key resides in memory and someone can find it.

无论您总是需要将密钥存储在某个地方。即使您决定(这很愚蠢)手动提供密钥,密钥也会驻留在内存中并且有人可以找到它。

Where you store it depends on your choice. However it should not be in plain text. So if you store a key in database, then use hard-coded secondary key in application. So if intruder has only access to db, then the encrypted main key is protected.

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

I would go for application configuration to store secondary key in container. That way only your application will have access to this properties. So the attacker will have to take control over your application or container to get access to that key.

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

So assuming following scenarios:

所以假设以下场景:

  1. Your application get hacked: attacker has the same permissions as you have. One can try to use your API to get sensitive information without playing at all with encryption. Your code will do it for them. Next option: she can try to get your war file or class files and decompile them to find out the hard-coded key, or learn about encryption mechanism you used.
  2. Only database is hacked: you should be fine having data encrypted with the key that is not in database itself.
  1. 您的应用程序被黑客入侵:攻击者拥有与您相同的权限。可以尝试使用您的 API 来获取敏感信息,而根本不使用加密。您的代码将为他们完成。下一个选项:她可以尝试获取您的War文件或类文件并对其进行反编译以找出硬编码的密钥,或者了解您使用的加密机制。
  2. 只有数据库被黑客入侵:您应该可以使用不在数据库本身中的密钥对数据进行加密。

To make it harder for attacker. You can place file in file system. As described in other answer add appropriate FS permissions to it. But additionally use java Security Manager to restrict access for all java classes except the one that really needs to read it. Also restricting modification to your jar and class files would be a good idea.

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

The more locks you have the more secure you are. As it is with standard door lock. The locks should be from different vendors and with different mechanisms. But at the end the skilled burglar will get into anyway.

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

回答by chro

Filesystem is ok,choose user permissions and use grant permission on war. There was a lot of security holes which open access only to database or war content

文件系统没问题,选择用户权限并对War使用授予权限。有很多安全漏洞只开放对数据库或War内容的访问