摘要

在基于 Unified Automation SDK開發(fā)OPC UA服務端時，用戶認證（User Authentication）是安全體系的第一道防線。除了傳輸層的加密通道外，服務端如何安全地存儲和驗證用戶信息至關重要。

本文不涉及復雜的代碼實現(xiàn)，而是通過分析典型服務端配置文件中的相關機制，闡述哈希算法（SHA-256）與加鹽（Salt）機制在OPC UA登錄環(huán)節(jié)的具體運行邏輯。

一、拒絕明文：服務端“存儲”的秘密

在 OPC UA的安全模型中，客戶端發(fā)送的密碼雖然經(jīng)過網(wǎng)絡層加密傳輸，但在服務端內(nèi)存中解密后依然是明文。 如果服務端直接將用戶密碼以明文形式寫入配置文件或數(shù)據(jù)庫，無疑是留給黑客的“后門”。

因此，標準的工業(yè)級實現(xiàn)（如基于Unified Automation SDK的后臺）通常采用 “哈希+加鹽” 的方式進行存儲。

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

這一長串看似亂碼的字符，恰恰是安全性的核心所在。

二、數(shù)據(jù)拆解：那串字符到底是什么？

以第一行用戶 john為例，逐字段解析：

• 用戶索引/ID (3)：內(nèi)部標識符。
• 用戶名 (john)：客戶端登錄時提供的身份標識。
• 算法標識 (sha256)：指定服務端在驗證時調(diào)用OpenSSL庫中的SHA-256算法。
• 迭代次數(shù) (1)：用于增加暴力破解難度（多次Hash運算），此處簡化為1次。
• 鹽值 (Salt)：F3E8...1908
• 隨機生成的 32字節(jié)（64個十六進制字符）。
• 即使不同用戶使用相同密碼（如 "123456"），由于Salt不同，最終生成的Hash值也完全不同，從而防御“彩虹表”攻擊。
• 哈希值 (Hash)：466D...545D
• 由 Hash(明文密碼+ Salt)計算得出。
• 服務端只存儲這個“指紋”，而不保存用戶的真實密碼。

三、驗證邏輯：當 John 登錄時發(fā)生了什么？

當客戶端發(fā)起 ActivateSession請求時，Unified Automation SDK內(nèi)部會執(zhí)行以下驗證流程：

• 接收輸入：服務端接收用戶名 john和解密后的嘗試密碼P。
• 查找記錄：讀取配置文件，定位到 john的記錄。
• 提取鹽值：獲取文件中的 Salt：F3E8BA4E...。
• 復現(xiàn)計算：

將嘗試密碼 P與Salt拼接。

調(diào)用 SHA-256算法計算：

New_Hash=SHA256(P+Salt)

比對結(jié)果：

• 若 New_Hash與配置文件中的Hash完全一致 → 密碼正確，允許登錄。
• 若存在差異 → 密碼錯誤，拒絕訪問。

四、總結(jié)

通過這個文件結(jié)構(gòu)可以看出，OPC UA服務端的安全性并不依賴于“隱藏密碼”，而是依賴于 單向加密邏輯：

• OpenSSL：提供底層SHA-256算法支持。
• OPCUA Server：在回調(diào)接口中整合并執(zhí)行驗證邏輯。
• 開發(fā)人員的任務：維護好 User DB文件，確保任何用戶的真實密碼不會以明文形式落在硬盤上。

以此類推，如果想在 Server端添加一個新的用戶認證賬戶，我們不能直接寫入明文密碼，而必須嚴格遵循上述格式：在該文件中新增一行記錄，配置好對應的用戶編號、用戶名、指定算法標識（如sha256）與配置位，并填入合規(guī)生成的隨機鹽值(Salt)以及計算后的哈希值(Hash)。

注： 由于人腦無法計算 SHA-256，實際操作中通常需要借助SDK自帶的工具或編寫簡單的腳本來生成這一行配置數(shù)據(jù)，直接手動編輯哈希字段是不可行的。