在spring xml文件中隐藏数据源密码
有没有办法在 xml spring 配置文件中隐藏/加密密码? 我读到,使用 DataSource 的“自定义”子类是可能的,但解决方案将密钥作为纯文本保存在同一配置文件中......所以有点无用。
有没有办法使用 KeyStore 来实现这一点? 例如,从密钥库读取值。
谢谢大家。
there is a way to hide/encrypt password in xml spring config file?
I read that is possible with a "custom" subclass of DataSource, but the solutions keep key in same config file as plain text...so is a bit useless.
There is a way to use KeyStore for this?
For example read the value from a keystore.
Thanks all.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
隐藏密码的目的是什么?我建议您在容器(Tomcat、JBoss 或您使用的任何容器)中配置数据源,并使用 jndi 将数据源注入到您的应用程序中:
这样您就不必在应用程序中公开密码,而只需在 servlet 容器中公开密码。
What is the purpose of hiding the password? I suggest you configure the datasource in the container (Tomcat, JBoss or whatever you use) and inject the datasource into your application using jndi:
This way you have not to expose and password in your application but only in the servlet container.
是的,你可以这样做。您必须围绕数据源类创建一个包装器 bean。这是我之前的做法的一个例子。希望这有帮助!
然后在 SecureDataSource 类中,您将需要解密密码。
Yes, you can do that. You will have to create a wrapper bean around the data source class. Here is an example of how I have done it before. Hope this helps!
Then inside the SecureDataSource class you will need to decrypt the password.
已经给出了很好的选择,另一个明显的答案是使用 PropertyPlaceholderConfigurer:
现在您可以将密码作为属性保存在属性文件中(如果您不想将其保留在 SCM 中,则可以在部署期间创建该文件) )或作为系统属性(希望其他开发人员也无法实现)。
澄清:在部署期间创建有点含糊。我想您将必须编写一个安装程序,在最终用户的计算机上动态生成属性文件,可能还需要加上注册/登录机制。
编辑:我仍然不知道你向谁隐藏了这些信息。两种理论:
a) 有权访问您的源代码的人
b) 你的客户
如果是a),那就走我的路。其他开发人员只需使用调试器启动您的应用程序(突然他就在数据源对象内部并看到密码),就可以轻松地破坏所有其他方法。
如果是b),那么基本上你就没有机会了。客户有很多可能性来获取您的密码:调试器、代理、字节码操作、加载时编织等。即使他不执行任何操作,他也只需附加一个端口嗅探器即可以明文方式获取密码文本。唯一安全的做法是为每个客户提供一个用户名/密码(切勿在客户的计算机上存储全局密码)。
Good options have been given, another obvious answer is to use the PropertyPlaceholderConfigurer:
Now you can keep your password either as a property in a properties file (which you might create during deployment if you don't want to have it in the SCM) or as a System Property (which will hopefully also be beyond reach of other developers).
Clarification: create during deployment is somewhat vague. I guess you will have to write an installer that generates the properties file dynamically on the end user's machine, probably coupled with a sign up / log in mechanism.
EDIT: I still haven't figured out who you are hiding the information from. Two theories:
a) People who have access to your source code
b) Your customers
If it's a), then go my way. All other ways can easily be breached by the other developer just starting your application with a debugger (and suddenly he's inside the datasource object and sees the password).
If it's b), then you have no chance, basically. The customer has tons of possibilities to get at your password: debuggers, agents, bytecode manipulation, loadtime weaving etc. Even if he doesn't do any of that, he will just have to attach a port sniffer to get at the password in clear text. The only safe thing to do is have a username / password per customer (never store a global password at your customer's machine).
我最近也有同样的问题。我想将密码的哈希版本存储在 .properties 文件中。
感谢前面的选项,我成功了:我扩展了 DelegatingDataSource 并重写了 getConnection([...]) 方法。
然后,这是我在
applicationContext.xml
中使用它的方式:其中
datasource.hash
是一个属性(来自 .properties 文件),存储如下:纯密码仍然是在字节码中,但不再直接在 .properties 文件中。
I had the same question recently. I wanted to store a hashed version of the password in a .properties file.
I did the trick thanks to the previous options: I extended the
DelegatingDataSource
and overrided thegetConnection([...])
methods.Then, here is how I used it in my
applicationContext.xml
:Where
datasource.hash
is a property (from a .properties file) stored like:The plain password is still in bytecode but not directly in a .properties file anymore.
感谢您的所有帖子和询问。
希望访问者通过阅读本页能够清楚密码加密的技术方法。我想在这里补充一件重要的事情,如果您正在处理生产,那么肯定会建议您使用任何“安全哈希算法”,例如带盐的 SHA-256。您可以考虑使用盐作为行业标准的安全哈希算法。
Thanks for all your post and queries.
Hope for visitors its clear the technical way to encrypt password by reading this page. One important thing I would like to add here, if you are dealing with production then definitely will suggest you to use any "Secure Hash Algorithm" like SHA-256 with salt. You can consider secure hash algorithm using salt as industry standard.