基于B/S 模式的信息化密码管理系统的设计与应用

李大同 陈昱希 张展飞 张文杰 廖南娇

引言

现如今，随着计算机技术的迅速发展，各类应用系统已广泛在企业的日常工作中使用，为企业办公自动化提供了很大的帮助，但同时也带来了诸多问题。随着信息管理系统数量的增加，不同的管理系统的登录模式、数据结构、体系架构和功能模块之间也有了很大的差异。由于上述的差异化，各个系统之间使用的登录方式有可能不同，但是使用多点登录的方式可能会导致各种各样的信息安全问题。为了解决这样的信息安全等问题，降低不同用户在运维过程中的复杂程度，打破不同信息系统之间的隔阂，建立企业的信息化应用平台，以此来提高开发效率，降低运维难度。

经过市场调研，许多企业对公共服务需要共享其账号密码是有比较大的需求的；首先是企业宣传运营管理部有很多媒体账号需要安全有序管理，比如公众号，官微账号，企业应用市场账号等；其次是企业HR也有很多招聘网站的账号密码需要管理；最后是企业各种内部管理工具，SaaS服务账号等。所以账号密码作为公司的重要虚拟资产，需要一个行之有效的管理方法，安全、精细管理。众所周知，当前所有企业基本都在进行企业管理信息化建设，那么针对其建设过程中面临的应用系统集成、用户身份管理等问题，本系统的开发可以实现信息系统统一、高效、安全的用户身份管理，以便于新应用系统的集成[1]。

一、系统架构

（一）技术架构

系统采用微服务部署，通过使用Docker容器来承载不同的业务，并且在网络层与系统层都部署了负载均衡的设备及应用，确保系统高可用的同时，当发生非法入侵时方便数字取证，且在后续的硬件或操作系统升级时，方便系统的迁移。具体如架构如图1所示。

图1 系统总体架构

（二）数据加密

需要考虑三种数据状态：

(1)传输中的数据；

(2)使用中的数据，即在服务器或客户端的内存或文件系统中的数据；

(3)静态数据，即电源关闭时在文件系统中的数据。

对于使用中的数据，只有密码会被加密。例如，用户名、评论或与共享密码的人员列表未使用OpenPGP加密，并以明文形式存储在客户端和服务器端。显然，密码在某些时候可以通过解密形式获得（越晚越好），但它们永远不会以明文形式存储在客户端或服务器端的文件系统中。

对于传输中的数据，例如在传输层级别，所有通信都使用SSL加密。该级别的安全强度不受本项目的密码管理平台解决方案本身的控制，而是由其他因素的组合控制，例如颁发证书的组织的安全级别和托管提供商选择的操作系统配置。

对于静态数据，在大多数客户端和服务器中，也可以在文件系统级别加密数据库，这将添加另一个有用的加密层。

二、底层架构及原理

（一）密码中的身份验证

本项目的密码管理平台不是经典的基于表单的身份验证，而是基于设置期间设置的OpenPGP密钥执行以及基于质询的身份验证。本章节的目的是帮助解释此身份验证过程如何工作以促进审查和讨论以及未来与其他产品的集成。授权技术多为基于访问控制模型和授权协议进行设计[1]。本项目的目标是提高整体解决方案的安全性和可用性，例如，重用本项目的密码管理平台的现有OpenPGP设施以避免让用户记住另一个密码而不是他们的密码。

1.基于表单的身份验证

虽然现在一些Web应用程序遵从其他服务（例如腾讯SSO及短信验证码）来处理身份验证，但大多数仍然默认支持基于表单的身份验证。在注册期间，密码被发送（最好通过HTTPS）到服务器。然后使用crypt（或等效）对该密码进行加盐和散列处理，并存储以供服务器进一步使用。只有此应用程序实例知道的盐用于防止密码的哈希值泄露（例如通过SQL注入）的暴力破解[3]。

在以与设置类似的方式发送登录期间，服务器对其进行哈希处理并将其与存储的版本进行比较。如果它们与服务器存储一个会话令牌，该令牌作为cookie（或URL参数）发送回并在客户端设置。此cookie由客户端在会话期间为每个请求生成（直到cookie过期、用户注销或服务器终止会话）。

2.基于表单的方法的问题

主要问题是可用性。将这种方法用于本项目的密码管理平台意味着用户需要在其私钥密码之上记住另一个密码。这抵消了拥有密码管理器的好处。

本项目还将密码存储在身份验证插件中，但这会使要求复杂化，因为它会引入本项目的密码管理平台用户账户密码创建、更新和恢复的需要。

另一个大问题是用户无法使用电子邮件验证重置密码，以防电子邮件客户端的密码存储在本项目的密码管理平台中。

其他问题不是本项目的密码管理平台特有的，但仍然值得尝试使用另一种方法来解决：比如网络钓鱼，密码质量等。

3.基于GPGAuth的身份验证

这个过程将遵循GPGAuth协议。该过程通过用户和服务之间加密和签名令牌的双向交换来工作。认证过程如图2所示：

图2 基于GPGAuth身份验证

4.验证步骤

（1）客户端生成随机数据的加密令牌（使用服务器公钥加密），并将未加密版本存储在本地。

（2）该加密令牌与用户密钥指纹一起发送到服务器。

（3）服务器根据用户密钥指纹检查用户是否存在以及是否处于活动状态。如果是这种情况，服务器将解密nonce并检查其格式是否有效。

（4）服务器发回解密后的随机数。

（5）客户端检查随机数是否与先前记录的随机数匹配。如果不匹配，客户端会警告用户无法验证服务器身份。

5.登录步骤

（1）用户发送他们的密钥指纹。

（2）服务器检查指纹和关联的用户是否有效。然后它生成随机数据的加密令牌，并将未加密版本存储在本地。

（3）服务器将未加密的签名用户令牌和加密的服务器令牌发送给用户。

（4）用户输入他们的私钥密码，客户端解密随机数并检查令牌格式。

（5）客户端将解密后的随机数与用户密钥指纹一起发回。

（6）服务器比较从客户端发送的未加密的签名令牌以确保它匹配。如果服务器满意，则与基于普通表单的登录一样完成身份验证：启动会话。

6.注释和备注

根据协议定义，服务器密钥验证步骤是可选的，但建议所有的客户端默认执行它。

在未来可能会尝试减少HTTP请求的数量：例如，目前不能在验证步骤中请求nonce1。因此，对于验证步骤，总共需要3个POST。整个协议可能会简化为单个GET/POST往返，例如基于表单的身份验证。

还有一个可选的“步骤0”，用户在其中执行GET/auth/verify请求。这可以用来获取服务器公钥和服务器验证的URL，或者查看服务器发布的公钥。

7.GPGAuth优点

除了不必记住额外密码的可用性优势之外，本项目还提供以下额外优势：

网络钓鱼：由于客户端不输入密码，因此降低了这种风险，例如，仅获取密钥密码将不允许攻击者登录。由于客户端可以根据服务器密钥（手动添加到密钥环）验证服务器身份，因此攻击者仅伪造表单和域是不够的。

密码质量：身份验证令牌的强度比经典密码强，因为每次也使用不同的“密码”，并且与私钥主密码的复杂性无关。

8.残留风险和缺点

目前的解决方案仍然存在风险：

服务器：客户端公钥有效性的完整性和验证。服务器可能会被诱骗存储错误的客户端公钥。为防止这种情况，服务器必须通过OpenPGP信任网络自动检查有效性和/或通过检查公钥服务器和/或必须由管理员进行手动检查。

由于加密/签名操作比基于“正常”表单的登录中的密码哈希操作成本更高，因此这些端点可能会被用来创建拒绝服务。为了降低这种风险，系统限制了尝试，例如随着时间的推移限制尝试的次数。

有关用户群的信息泄露。攻击者可以通过请求加密的随机数并收到错误来查明用户是否在服务器上拥有账户。在标头中泄露信息以提高可用性并提供更好的错误消息：例如，告诉用户其账户已被删除。

服务器公钥的完整性和验证。客户端可能会被诱骗存储无效的服务器密钥。为防止这种情况，客户端必须在设置期间检查有效性（如前例）。同样，在设置期间，客户端还必须检查域/密钥映射，以防有人使用虚假但非常相似的域URL创建真实密钥。目前已实施，但肯定可以改进，因为最终用户仍然可能犯错误并且无法正确检查。

客户端/服务器可能被诱骗解密并返回/签署错误数据，例如攻击者先前捕获的电子邮件。为了缓解这种情况，加密格式消息是固定的（例如UUID）并由服务器签名。如果SSL可以破解，身份验证cookie就可以被窃取。这并非特定于此身份验证方法，因为表单身份验证也容易受到此类攻击。此外是没有替换和撤销密钥的工具。

（二）角色和权限

1、系统角色

本项目的密码管理平台提出了两个系统角色管理员和用户。该系统是授权机制的第一线，直接对每个用户的操作执行检查。

简而言之，管理员管理实例。实际上，这意味着他们可以管理组织范围内的设置，例如电子邮件通知的内容或启用了哪个多因素身份验证提供程序。另一个职责是创建或删除用户、管理组和组管理员、执行与用户目录的同步等。

2、组级角色

每个群必须至少有一个群管理员负责添加和删除群成员。管理员可以指定自己为组管理员或指定普通用户，具体关系如图3所示。

图3 角色关系

由于本项目的密码管理平台中加密的性质，只有有权访问给定组的秘密的人才能将成员添加到该组（因为他们需要能够为新成员解密和加密密码）。

3、资源级角色

本项目的密码管理平台在资源层面提供三种权限：

（1）所有者：可以管理共享设置、删除、更新、读取。

（2）更新：可以更新记录和删除。

（3）读取：只能读取和使用密码元数据和秘密。

4、文件夹级别角色

在系统底层，文件夹权限将重用于资源可用权限系统相同的权限系统。这将允许用户将一组权限关联到一个或多个文件夹。与资源一样，文件夹必须具有在文件夹权限中定义的所有者权限。还有两种其他权限类型可用：更新和读取。

一旦项目位于文件夹中，可以对项目执行的操作不取决于文件夹权限，而是项目本身，就像在常规文件系统上一样。对于要移动文件夹内的项目的用户，他们通常必须至少具有对该项目和目标文件夹的更新权限。

三、应用工作原理

（一）系统接口

密码服务器组件API 以 REST 方式在 HTTPS 上工作，因此它与语言框架无关。可以使用适合的工具集将密码管理服务集成到现有的工作流程中[2]。要开始使用密码管理 REST API（以下简称“API”），至少需要：

（1）一个正在运行的密码服务器实例。

（2）如果您想访问受保护的数据，请使用密码用户帐户。

（3）对公钥加密的工作原理有一些基本的了解。

（4）用于构建的OpenPGP 兼容库。

API 通过 HTTPS 提供。本文中引用的所有 URL 都省略了密码安装域的基本 URL，例如：https://.

（二）响应包结构

API 在具有“header”和“body”属性的信封中返回数据。“header”包含响应元数据，如响应代码、server_time、错误消息等。“body”包含实际有效负载。

（三）错误响应

不成功的操作将导致错误响应。错误响应将遵循与上面相同的方案，同时存在“header”和“body”属性，只是这次标题中的状态将设置为 error而不是success。响应正文将包含错误详细信息。

如上所示，对于验证错误，响应正文包含两个键，“name”和“secrets”，因为它们未通过某些验证规则。此外，它们还有自己的 json 对象，其中包含一个表示失败的验证规则的键（“_required”）和一个包含实际错误消息的值（“A name is required”）。

（四）访问密码服务器公钥

在身份验证的“验证”步骤中需要密码管理服务器公钥。此步骤允许客户端验证服务器身份，例如防止域被占用等不太可能的情况。密码管理服务器在/auth/verify.json 广播其公钥：

结语

构建具备高可靠性的统一身份认证体系，对于复杂商用环境特别是金融业业务系统大集中的场景下意义重大。随着软件开发技术的不断发展，目前各大企业均构建了面向不同业务领域的系统，企业中多项目的团队尤其是初期阶段会尝试很多系统，人员流动也比较大，要有效地管理好账号密码，在新员工入职时可以迅速发放，员工离职时可以快速收回，并且在密码使用过程中尽可能保障安全，线上服务器密码管理也是比较重要的一环。目前，该系统已经在本市的某企业部署应用，并且取得了良好的应用效果，大幅提升了运维人员的运维效率，实现了对企业数字资产的统一控制。