摘要

在基于Unified Automation SDK开发 OPC UA 服务端时，用户认证（User Authentication）是安全体系的第一道防线。除了传输层的加密通道外，服务端如何安全地存储和验证用户信息至关重要。本文不涉及复杂的代码实现，而是通过分析一个典型的服务端配置文件内的相关机制，展示哈希算法（SHA-256）与加盐（Salt）机制在 OPC UA 登录环节的具体运行逻辑。

一、拒绝明文：服务端“存储”的秘密

在 OPC UA 的安全模型中，客户端发送的密码虽然经过网络层加密传输，但在服务端内存中解密后依然是明文。 如果服务端直接将用户密码以明文形式写入配置文件或数据库，无疑是留给黑客的“后门”。因此，标准的工业级实现（如基于 Unified Automation SDK 的后台）通常采用“哈希 + 加盐”的方式进行存储。

示例配置文件片段（User DB）：

Line 1: 3 john sha256 1 F3E8BA4E3***41C2BCC4EA1B764B1908 466D434BB5BC1B34B65BBAC1D2C1C32ACD9431B958C5E9C698936245******** Line 2: 4 sue sha256 1 5D546C33F***407196443F339E2CD780 51F6A6BB3DC40770F22D5C7B8E33BB386A64950197338D81F57EF40D********

这一长串看似乱码的字符，恰恰是安全性的核心所在。

二、数据拆解：那串字符到底是什么？

以第一行用户john为例，逐字段解析：

• 用户索引/ID (3)：内部标识符。

• 用户名 (john)：客户端登录时提供的身份标识。

• 算法标识 (sha256)：指定服务端在验证时调用 OpenSSL 库中的 SHA-256 算法。

• 迭代次数 (1)：用于增加暴力破解难度（多次 Hash 运算），此处简化为 1 次。

• 盐值 (Salt)：F3E8...1908

  • 随机生成的 32 字节（64 个十六进制字符）。

  • 即使不同用户使用相同密码（如 "123456"），由于 Salt 不同，最终生成的 Hash 值也完全不同，从而防御“彩虹表”攻击。

• 哈希值 (Hash)：466D...545D

  • 由Hash(明文密码 + Salt)计算得出。

  • 服务端只存储这个“指纹”，而不保存用户的真实密码。

三、验证逻辑：当 John 登录时发生了什么？

当客户端发起ActivateSession请求时，Unified Automation SDK 内部会执行以下验证流程：

1. 接收输入：服务端接收用户名john和解密后的尝试密码P。

2. 查找记录：读取配置文件，定位到john的记录。

3. 提取盐值：获取文件中的 Salt：F3E8BA4E...。

4. 复现计算：

   • 将尝试密码P与 Salt 拼接。

   • 调用 SHA-256 算法计算：

New_Hash=SHA256(P+Salt)

比对结果：

若 New_Hash 与配置文件中的 Hash 完全一致 → 密码正确，允许登录。
若存在差异 → 密码错误，拒绝访问。

四、总结

通过这个文件结构可以看出，OPC UA 服务端的安全性并不依赖于“隐藏密码”，而是依赖于单向加密逻辑：

• OpenSSL：提供底层 SHA-256 算法支持。

• OPCUA Server：在回调接口中整合并执行验证逻辑。

• 开发人员的任务：维护好 User DB 文件，确保任何用户的真实密码不会以明文形式落在硬盘上。

以此类推，如果想在 Server 端添加一个新的用户认证账户，我们不能直接写入明文密码，而必须严格遵循上述格式：在该文件中新增一行记录，配置好对应的用户编号、用户名、指定算法标识（如 sha256）与配置位，并填入合规生成的随机盐值 (Salt)以及计算后的哈希值 (Hash)。

注：由于人脑无法计算 SHA-256，实际操作中通常需要借助 SDK 自带的工具或编写简单的脚本来生成这一行配置数据，直接手动编辑哈希字段是不可行的。