在Java Web应用程序中存储密码变量的不同方法？
我已经实现了一个例程，当用户提交表单时，会向管理员发送电子邮件。 为此，我使用了Java Mail API。 我在Microsoft Outlook上设置了一个虚拟帐户，用于发送电子邮件。 在代码中我硬编码了密码。 我担心当我托管网页时这将是一个安全问题。
这是我的代码。
我写了一个私函数：
private void getSession(){ this.session = Session.getDefaultInstance(properties, new javax.mail.Authenticator() { protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication("xxxxxxxxx@outlook.com", "xxxxx_password_xxx"); } }); } 在我的public execute()方法中，我调用getSession()方法并生成消息。
public String execute() throws Exception { getSession(); Message message = new MimeMessage(this.session); message.setFrom(new InternetAddress("xxxxxxxxxxxxx@outlook.com")); message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("admins.email@xxxxx.com")); message.setSubject("Form submit notification"); //... }
在我托管网页时，在会话方法中对密码进行硬编码是否安全？
如果没有，那么一些指针来实现替代方案。
谢谢！
在这种情况下，他无法散列密码。 只有在需要CHECKED且未使用时才能对密码进行哈希处理。 使用密码（即后端需要登录到SMTP服务器以发送电子邮件，或者到另一个数据库以提取数据）意味着需要知道它。
在这种情况下，有3 + 1级别的替代方案，基本上将不安全因素从代码转移到其他地方。 但是在给定相同的程序前提条件下，攻击者将始终能够恢复密码。 到达他们的可能性衡量该密码的安全级别。
- 在明文中，在配置文件中 – 密码可以存储在文件系统中的某个配置文件中; 显然，如果它是一个webapp，它不能是webroot，但在其他地方受到很好的保护
- 在配置文件中加密; 加密/解密的密钥必须存储在不同的文件中，而不是存储在代码中。 当两个文件存储在不同的文件系统中时，此方法最适用
- 在配置文件中加密; 加密/解密的密钥不存储在任何文件系统上。 在启动时询问正在启动应用程序的操作员; 检查该密钥是否正确（否则，应用程序无法启动），如果是，则将其存储在内存中。
- [不是普通人的真正替代方案] HSM硬件安全模块：这种类型的设备以“安全”的方式存储密钥和值。 这通常意味着服务器（您的应用程序）具有PCI /硬件模块，该模块物理地授予连接和检索存储在HSM中的某些密钥。 解密配置文件的密钥存储在HSM中，由于服务器连接具有PCI硬件，它可以检索该密钥并解密配置文件。
贬低这些解决方案的风险
0–在srcs中硬编码的密码 – >风险与代码检索的简易性有关; 即使在C / C ++中，反编译以提取带编码的字符串并不困难，在Java和.NET中它是微不足道的
- 配置文件中的密码，明文 – >风险与文件系统中特定文件的检索简易性有关; 通常这很难，因为代码在存储库中共享，在不同的人之间共享，而托管应用程序的文件系统由较少的人访问
- 配置文件中的密码，加密 – >风险与上述相同 ！ 我知道这听起来很奇怪，但请相信我：用密钥“关闭”加密密码，或者用明文加密密码是一样的！
- 配置文件中的密码，已加密，未存储密钥 – >风险与读取运行密码的服务器中的内存的难易程度有关。 在C / C ++中，你需要成为root AFAIK。 在Java中，您可以将其作为启动该流程的同一用户。 在这两种情况下，它都需要完全访问系统
- 配置文件中的密码，加密，HSM中的密钥 – >您必须完全控制服务器，通常是root，然后了解HSM必须检索密钥的API。 它与完全访问服务器的可能性有关。
当然，从1到3，实现变得更加困难。 4是HSM的api的问题。
它不是一个好的软件实践，可能导致安全问题。
密码更改时，它也可能导致问题。 您必须重新编译代码才能更新应用程序。
以下是一种不必硬编码密码的建议方法，因此可以使您的软件更加灵活和安全。
CWE-259：使用硬编码密码
如上面的链接所示：对密码应用强单向哈希，并将这些哈希值存储在具有适当访问控制的配置文件或数据库中。 这样，盗窃文件/数据库仍然需要攻击者试图破解密码。 在身份validation期间接收传入密码时，请获取密码的哈希值并将其与您保存的哈希值进行比较。
为您生成的每个单独哈希使用随机分配的salt。 这增加了攻击者进行暴力攻击所需的计算量，可能会限制彩虹表方法的有效性。