WPF PasswordBox 密碼驗證：SecureString 轉 String 的安全性深度剖析

核心爭議點

WPF PasswordBox 以 SecureString 存儲密碼（記憶體加密、非托管堆、可銷毀），但實務中常見 SecureString → String 轉換後再驗證/傳輸，引發安全性質疑。

為何會轉 String？

• 舊版 API/資料庫驅動/身份驗證庫（如 AD、SQL 連線字串）僅接受 string。
• 需與非 .NET 系統交互（Web API、LDAP、第三方 SDK）。
• 單元測試、日誌調試便利性。

安全性影響評估

最佳實踐模式

// 僅在邊界處轉換，用完即銷毀
public bool VerifyPassword(SecureString securePwd, string storedHash)
{
    IntPtr bstr = IntPtr.Zero;
    try
    {
        bstr = Marshal.SecureStringToBSTR(securePwd);
        string plain = Marshal.PtrToStringBSTR(bstr);
        // 使用強雜湊驗證
        return Argon2.Verify(storedHash, plain);
    }
    finally
    {
        if (bstr != IntPtr.Zero) Marshal.ZeroFreeBSTR(bstr);
        // plain 變量離開作用域等待 GC，敏感場景可考慮 unsafe 手動清零
    }
}

進階替代方案

1. 全鏈路 SecureString：.NET Core 3.0+ SqlConnection 支援 SecureString 密碼屬性，避免轉換。
2. 零知識證明/挑戰-響應：客戶端不發送密碼，僅發送雜湊/簽名（如 SCRAM、WebAuthn）。
3. 硬體隔離：TPM/HSM/KMS 管理金鑰，應用層僅持有句柄。
4. 記憶體加固：GCHandle.Alloc(bytes, GCHandleType.Pinned) + RtlZeroMemory 手動清零，配合 [SuppressUnmanagedCodeSecurity]。

總結

轉 String 本身不等於不安全，關鍵在於「轉換後怎麼用、存多久、傳多遠」。遵循最小暴露原則：邊界轉換、強雜湊、加密傳輸、即時銷毀、審計日誌脫敏。單純依賴某種技術（如 SecureString）並不能保證絕對安全，威脅建模與纵深防禦才是正道。