在属性文件中保护密码

Question

我有一个连接数据库的Java应用程序。数据库的用户名和密码存储在属性文件中。避免在属性文件中以明文形式存储密码，同时仍保留允许用户更改选项的常见做法是什么？这里的主要动机是防止在管理员编辑属性文件时有人看着管理员的肩膀并看到密码。我在这里阅读到有一种内置的方法可以在C＃中完成。了解Java，我不希望找到一个内置的解决方案，但我想听听其他人在做什么。如果找不到任何好的选择，那么我可能会使用将保留在代码中的恒定密码对其进行加密。但是我不喜欢这样做，因为它感觉不对。 看起来没有魔法，我必须将密码存储在代码中或类似的内容中。最后，我们实现了与答案之一中提到的Jasypt非常相似的东西。所以我接受Jasypt答案，因为它是最确定的答案。

Answer 1

穷人妥协解决方案是使用简单的多重签名方法。

例如，DBA将应用程序数据库密码设置为50个字符的随机字符串。 TAKqWskc4ncvKaJTyDcgAHq82X7tX6GfK2fc386bmNw3muknjU

他或她将一半的密码提供给应用程序开发人员，然后将其硬编码为Java二进制文件。

私人字符串pass1 =“ TAKqWskc4ncvKaJTyDcgAHq82”

密码的另一半作为命令行参数传递。DBA将pass2交给系统支持人员或管理员，后者可以输入pass2作为应用程序的启动时间，或者将其放入自动化的应用程序启动脚本中。

java -jar /myapplication.jar -pass2 X7tX6GfK2fc386bmNw3muknjU

当应用程序启动时，它使用pass1 + pass2并连接到数据库。

该解决方案具有许多优点，而且没有提及的缺点。

您可以安全地将一半密码放在命令行参数中，因为除非您是拥有另一半密码的开发人员，否则阅读它不会有多大帮助。

DBA仍然可以更改密码的后半部分，并且开发人员无需重新部署应用程序。

读取源代码时，源代码也可以是半公开的，并且密码不会授予您应用程序访问权限。

您可以通过增加对数据库将接受其连接的IP地址范围的限制来进一步改善这种情况。

Answer 2

如何提供自定义的N因素身份验证机制？

在合并可用方法之前，让我们假设我们可以执行以下操作：

1）Java程序内部的硬代码

2）存储在.properties文件中

3）要求用户从命令行键入密码

4）要求用户从表格中输入密码

5）要求用户从命令行或表单加载密码文件

6）通过网络提供密码

7）许多替代方法（例如，“画出秘密”，指纹，特定于IP，bla bla bla）

第一种选择：我们可以通过混淆使攻击者的事情变得更复杂，但这并不是一个好的对策。优秀的编码人员可以访问文件，从而轻松理解其工作原理。我们甚至可以导出每个用户的二进制文件（或仅导出混淆部分或密钥部分），因此攻击者必须有权访问此用户特定的文件，而不是另一个发行版。同样，我们应该找到一种更改密码的方法，例如通过重新编译或使用反射来即时更改类行为。

第二个选择：我们可以将密码以加密格式存储在.properties文件中，因此攻击者无法直接看到它（就像jasypt一样）。如果我们需要密码管理器，我们也将需要一个主密码，该密码又应该存储在某个地方-在.class文件，密钥库，内核，另一个文件甚至在内存中-都有各自的优缺点。
但是，现在用户只需编辑.properties文件即可更改密码。

第三个选项：从命令行运行时输入密码，例如java -jar /myprogram.jar -p sdflhjkiweHIUHIU8976hyd。

不需要存储密码，它将保留在内存中。但是，history命令和OS日志可能是您最大的敌人。要即时更改密码，您将需要实现一些方法（例如，监听控制台输入，RMI，套接字，REST等等），但是密码将始终保留在内存中。

甚至可以仅在需要时才对其进行临时解密->然后删除解密的内容，但始终将加密的密码保留在内存中。不幸的是，前述方法并未增加针对未经授权的内存中访问的安全性，因为实现该目的的人可能将有权访问所使用的算法，盐和任何其他秘密。

第四个选项：从自定义表单（而不是命令行）提供密码。这将避免测井暴露的问题。

第五个选项：提供一个文件作为密码，该文件先前存储在另一种介质上->然后硬删除文件。这将再次规避伐木暴露的问题，再也不需要敲击可能会被偷来的打字。如果需要更改，请提供另一个文件，然后再次删除。

第六种选择：再次避免肩并肩冲浪，可以实施RMI方法调用，从另一个设备（例如，通过移动电话）提供密码（通过加密通道）。但是，您现在需要保护网络通道并访问其他设备。

我将选择上述方法的组合以实现最大的安全性，因此必须访问.class文件，属性文件，日志，网络通道，肩膀冲浪，中间人以及其他文件。使用所有sub_password之间的XOR操作可以很容易地实现此操作，以产生实际的密码。

但是，我们不能免受未经授权的内存访问的保护，这只能通过使用某些访问受限的硬件（例如，智能卡，HSM，SGX）来实现，其中将所有内容都计算在内，没有任何人，甚至没有合法的所有者能够访问解密密钥或算法。同样，人们也可以窃取这种硬件，据报道有侧通道攻击可以帮助攻击者提取密钥，在某些情况下，您需要信任另一方（例如，使用SGX，您可以信任英特尔）。当然，当安全区域克隆（拆装）成为可能时，情况可能会恶化，但是我认为这将需要几年才能实现。

同样，可以考虑一种密钥共享解决方案，其中将完整密钥分配给不同的服务器。但是，在重建时，完整密钥可能会被盗。缓解上述问题的唯一方法是通过安全的多方计算。

我们应该始终牢记，无论采用哪种输入方法，都需要确保我们不容易受到网络嗅探（MITM攻击）和/或键盘记录程序的攻击。