在Java Web应用程序中存储密码变量的不同方法？[关闭]

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

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

以明文形式在配置文件中-密码可以存储在文件系统中某个位置的配置文件中；显然，如果它是一个Web应用程序，则一定不能是Webroot，而应在其他受良好保护的地方
在配置文件中加密；加密/解密密钥必须存储在其他文件中，而不是代码中。当两个文件存储在不同的文件系统中时，此方法最适用
在配置文件中加密；加密/解密的密钥未存储在任何文件系统上。在启动时要求启动该应用程序的操作员。检查该密钥是否正确（否则，应用程序无法启动），如果正确，则将其存储在内存中。
[不是普通人的真正替代品] HSM硬件安全模块：这种类型的设备以“安全”的方式存储密钥和值。这通常意味着服务器（您的应用程序）具有一个PCI /硬件模块，该模块从物理上授权连接并检索存储在HSM中的某些密钥。用于解密配置文件的密钥存储在HSM中，由于连接的服务器具有PCI硬件，因此它可以检索该密钥并解密配置文件。

这些解决方案的风险

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

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

当然，从1到3，实现变得更加困难。4是HSM的api问题。