在Java Web应用程序中存储密码变量的不同方法? [英] Different ways to store a password variable in a Java web application?

问题描述

我实现了一个例程，当用户提交表单时，会将电子邮件发送给管理员.为此，我使用了Java Mail API.我在Microsoft Outlook上设置了一个虚拟帐户，用于发送电子邮件.在代码中，我对密码进行了硬编码.我担心在托管网页时这将是一个安全问题.

I have implemented a routine where when a user submits a form an email is sent to the administrator. For this I have used Java Mail API. And I setup a dummy account on Microsoft Outlook for sending out the emails. In the code I have hard-coded the password. I am concerned this will be a security issue when I host the webpage.

这是我的代码.

我写了一个私有函数:

private void getSession(){
    this.session = Session.getDefaultInstance(properties,  
    new javax.mail.Authenticator() {
        protected PasswordAuthentication 
        getPasswordAuthentication() {
            return new PasswordAuthentication("[e-mail]", "xxxxx_password_xxx");
        }
    });
}

在我的公共execute()方法中，我调用getSession()方法并生成消息.

In my public execute() method I call the getSession() method and generate the message.

public String execute() throws Exception {
     getSession();
     Message message = new MimeMessage(this.session);
     message.setFrom(new InternetAddress("[e-mail]"));
     message.setRecipients(Message.RecipientType.TO, 
                          InternetAddress.parse("[e-mail]"));
     message.setSubject("Form submit notification");
     //...
}

托管网页时，在会话方法中对密码进行硬编码是否安全?

Is it secure to hard code the password in the session method when I host the web page?

如果没有，那么一些实现替代方案的指针.

And if not, then some pointers to implement the alternatives.

谢谢！

推荐答案

在这种情况下，他无法对密码进行哈希处理.仅当需要检查而不使用密码时，才可以对密码进行哈希处理.使用密码(即后端需要登录SMTP服务器以发送电子邮件，或登录另一个数据库以提取数据)意味着需要知道它.

In this case he can't hash the password. A password can be hashed only when it needs to be CHECKED and not USED. Using the password (i.e. the back end needs to login to an SMTP server to send an email, or to another database to extract data) implies the need to know it.

在这种情况下，存在3 + 1级别的替代方案，基本上将不安全性从代码转移到了其他地方.但是，只要程序具有相同的前提条件，攻击者将始终能够恢复密码.进入密码的​​可能性衡量该密码的安全级别.

There are 3+1 levels of alternatives in this case, basically shifting the insecurity from the code to somewhere else. But the attacker will always be able to recover the password given the same pre-conditions of the program. The likelihood of getting to them measures the level of security of that password.

1. 以明文形式在配置文件中-密码可以存储在 配置文件在文件系统中的某个位置；清楚地知道这是否是 webapp，它一定不能是webroot，但可以在其他受到良好保护的地方
2. 加密在配置文件中；加密/解密密钥必须存储在 不同的文件，而不是在代码中.此方法最适用于以下情况 这两个文件存储在不同的文件系统中
3. 加密在配置文件中；加密/解密的密钥未存储 在任何文件系统上.在启动时要求操作员 启动应用程序；检查此密钥是否为 对的(否则，应用程序无法启动)，如果是，则 存储在内存中.
4. [不是普通百姓的真正替代品] HSM硬件安全模块:这种类型的设备以安全"的方式存储密钥和值.这通常表示服务器(您的 应用程序)具有一个PCI/硬件模块，可在物理上授予 连接和检索存储在HSM中的某些密钥.钥匙 用于解密配置文件的文件存储在HSM中，并且由于 服务器连接具有PCI硬件的事实，它可以 检索该密钥并解密配置文件.

1. in clear-text, in a configuration file - the password can be stored in a configuration file somewhere in the filesystem; clearly if it is a webapp, it must not be the webroot, but somewhere else well protected
2. encrypted in a configuration file; the key for encryption/decryption must be stored in a different file, and not in the code. This method best applies when the two files are stored in different filesystems
3. encrypted in a configuration file; the key for encryption/decryption is not stored on any filesystem. It is asked at boot to the operator that is starting the application; a check is made whether this key is the right one (otherwise, the application can't start) and if it is, it is stored in memory.
4. [not a real alternative for common people] HSM Hardware Security Module: this type of device stores key and values in a "secure" way. This usually means the server (your application) has a PCI/hardware module that physically grants the connection and the retrieval of some keys stored in the HSM. The key for decryption of the config file is stored in the HSM and due to the fact the server connecting has the PCI hardware, it can retrieves that key and decrypt the config file.

这些解决方案的风险

0--用srcs硬编码的密码->风险与 code 的获取容易有关；即使在C/C ++中，反编译以提取经编码的字符串也不难，在Java和.NET中，它是微不足道的，即时的

0-- Password hardcoded in srcs --> The risk is connected to the ease of retrieval of the code; decompilation to extract harcoded strings is not difficult even in C/C++, in Java and .NET is trivial and instant

1. 配置文件中的密码，明文->风险与文件系统中特定文件的容易获取有关；通常这比较困难，因为代码是在存储库中共享，在不同的人之间共享，而托管该应用程序的文件系统却很少有人访问
2. 配置文件中的密码已加密->风险与上面的相同相同！我知道这听起来很奇怪，但是请相信我:使用密匙密"对密码进行加密或以明文形式进行加密都是一样的！
3. 配置文件中的密码，已加密，没有密钥存储->风险在于与读取运行密码的服务器中的内存有关.在C/C ++中，您需要是根AFAIK.在Java中，您可以与启动该进程的用户相同.在这两种情况下，都需要完全访问系统
4. 配置文件中的密码(已加密)，是HSM中的密钥->您必须完全控制服务器(通常是root用户)，然后了解HSM必须使用哪个API来检索密钥.它与完全访问服务器的可能性有关.

1. Password in a config file, cleartext --> The risk is connected to the ease of retrieval of a specific file in the filesystem; usually this is harder as the code is shared in repositories, shared among different people, while the filesystem hosting the app is accessed by less people
2. Password in a config file, encrypted --> The risk is the same above! I know it sounds strange, but trust me: having a password encrypted with a key "close" to it, or having it in cleartext is the same!
3. Password in a config file, encrypted, no key stored --> The risk is connected to the ease of reading the memory in the server running the password. In C/C++ you need to be root AFAIK. In Java you can do it being the same user who launched the process. In both cases it needs complete access to the system
4. Password in a config file, encrypted, key in the HSM --> You have to get the full control of the server, usually being root, and then understand which API the HSM has to retrieve the key. It is connected to the likelihood of having complete access to the server.

当然，从1到3，实现变得更加困难. 4与HSM的api有关.

Of course, from 1 to 3, the implementation gets much harder. 4 is a matter of the HSM's api.

这篇关于在Java Web应用程序中存储密码变量的不同方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！