在配置文件中加密密码的标准?

信息安全 加密 应用安全 密码
2021-08-19 10:59:52

我的工作场所有一个标准,即应用程序配置文件中不允许使用明文密码。从表面上看,这很有意义,以防有人访问配置文件,他们不会自动访问该应用程序的所有权限。在某些情况下,可能而且显然更可取的是与登录相关联的访问权限或以其他方式避免使用密码,例如在 Windows 安全性中用于 SQL Server 身份验证,或者将其配置在第三方位置,例如 J2EE 环境中的 JDBC 配置,但这并不总是可能的。

  • 当我必须在配置文件中有密码时,它应该携带什么级别的加密?
  • 您如何处理密码的加密密钥必须是硬编码或存储在另一个配置文件中的事实?
  • 密码的加密密钥应该是人类可读的吗?
4个回答

如果您运行的服务器需要密码才能访问某些远程服务,那么没有好的解决方案。将密码存储在存储在适当位置的配置文件中可能是在一系列糟糕的选择中做出最好的选择。

选择是:让用户在启动时输入密码(这很糟糕,因为如果您的服务器重新启动,现在服务器将无法访问,直到有人可以亲自走到服务器并输入密码);将密码硬编码到服务器代码的源代码中(这比将其放入配置文件中要糟糕得多);或将密码存储在配置文件中(所有选项中最不坏的)。配置文件要注意的主要事情是确保它存储在您的 Web 根目录之外,并且它的文件权限被适当地锁定。

加密存储在配置文件中的密码没有帮助,因为现在您将解密密钥存储在哪里?你只是转移了问题。“一直是乌龟”是不可接受的回应。

在 Windows 上,您可能会看到的另一个选项是将密码存储在 DPAPI 中。这对桌面应用程序有一点帮助,但对无人值守的服务器不是很有用。

有关更多信息,请阅读本网站上的以下问题: 存储密码以避免用户交互在哪里存储用于加密的密钥开源项目如何处理安全工件?, 如何在不硬编码密钥的情况下使用 Java 解密数据?密码文件.PHP我在哪里可以安全地存储于系统中,如果源是可见的关键?.

PS 原则上,您可以使用 TPM 来存储密码——但在实践中,这会使您陷入前沿问题,因此对于大多数人来说可能不可行。

所以下面的评论有点太长了......

也许退后一步,比较预防性和检测性控制的好处可能会有所帮助。预防性控制包括加密,但您也可以对密码进行编码以使其不那么明显。这种方法旨在保护密码不被意外共享(b32 编码会产生不太有意义的字符(b32 产生的字符串比 b64 长)。这种方法只会增加记忆随机数字序列的难度以及应该用于解码字符串。Base32/64 编码是一种保护密码的简单方法,不需要构建/维护额外的逻辑。

预防性控制的其他方法可能会使用加密。有许多不同的方法来保护密钥。无需深入了解细节或重申 DW 已经发布的内容,您可以分层检测控制以改善安全状况。例如,您可以审核对包含密钥的文件的访问。您可以将事件(例如重新启动服务器/服务)与对密钥文件的访问相关联。对密钥文件的任何其他访问请求(成功与否)都可能表明活动异常。

为了回答你的问题,这是我的看法:

如果您必须将密码存储在配置文件中,我建议至少在可能的情况下对密码进行编码。对密码进行编码将减少在有人滚动文件时泄露的机会,例如在供应商支持代表观看的情况下。加密密码更安全,但这需要额外的复杂性。

如何处理密钥必须被硬编码或存储在另一个文件中的事实。好吧,将加密密钥分离到另一个文件中会增加某人查看密钥的难度。例如,您可以使用访问控制来限制对密钥文件的访问,但仍为配置文件维护更开放的 ACL。同样,您可以对密钥文件的访问实施审计,您可以使用该文件将需要使用密钥的事件关联回。如果您限制对二进制文件的访问,对密钥进行硬编码可能会很好。通过对二进制文件运行“字符串”可以很容易地检测到密码的仔细编码。您可以在解码密码时对硬编码密码进行编码/加密(即需要单独的功能(可能带有审核),但这会增加开发人员和管理员的复杂性(即

密码的加密密钥应该是人类可读的吗?这取决于。保护密钥的方法有限。加密密钥通常被视为难以写入内存的字母数字字符串。您始终可以对密钥进行编码/加密,但这些方法并不能阻止聪明到可以截屏的人。但是,您可以使用简单的“键”(更像是密码)作为键扩展功能的输入。在这些情况下,相对于复杂性的成本,编码等额外措施可能会增加一些额外的价值。

如果有的话,一个好的方法是实现多层控制。预防性控制更加困难,而检测性控制通常更容易实施。分离关键文件可以简化控制的整体架构和实施。无论使用预防性控制还是检测性控制,都必须启用一些审计功能以及审查审计日志。这样,如果发生不可能的事情(访问密钥),您可以采取纠正措施。

本地密码存储是我一直在处理的一个长期问题。由于加密不会是防弹的,但可能会有所帮助,因此几乎没有其他选择:

  1. 将本地计算机上的密码存储在一个新文件中(最好也加密)并限制对该文件的访问
  2. 将密码存储在另一台服务器中,该服务器将通过 OAUTH 或其他身份验证服务进行身份验证 - 查看 tahoe-lafs:https ://tahoe-lafs.org/trac/tahoe-lafs
  3. 使用存储密码的加密本地服务,并使用证书访问它
  4. 一些组织将其密码存储为注册表项或使用 DPAPI - http://msdn.microsoft.com/en-us/library/ms995355.aspx
  5. 使用 OTP 使用帐户管理服务
  6. 使用代理服务器访问机密数据并限制对代理的访问

.

对于您的问题:

当我必须在配置文件中有密码时,它应该携带什么级别的加密?

您永远不必在代码中设置密码,但这是最简单且最不安全的方法。

您如何处理密码的加密密钥必须是硬编码或存储在另一个配置文件中的事实?

使用访问限制和监控文件

密码的加密密钥应该是人类可读的吗?如果您的意思是强且人类可读的密码,则完全没有问题

将密码存储在(非会话)O/S 用户环境变量中,并以该用户身份运行程序。

好处:

  1. 您永远不会不小心将密码签入源代码管理,因为没有要签入的文件。

  2. 如果你搞砸了你的配置文件的文件权限(这永远不会发生对吗?),你的密码不会被泄露

  3. 只能由用户或 root 读取(与配置文件相同,与保护加密文件的私钥相同)

  4. 如果您正在加密文件,您如何保护您的密钥?

  5. 不过,在开始新进程之前清除您的环境变量,因为它们可能会通过

HSM 的一个优点是,虽然用户或 root 可以使用HSM 解密一个值,但他们永远无法获得其中的密钥。