无需修改应用程序加密SQL Server明文密码的方案咨询

一、SQL Server开箱即用的零应用修改加密方案可能性 #

首先明确：如果要求完全不修改Delphi 7应用，SQL Server的开箱即用方案中只有透明数据加密（TDE）能做到，但它有局限性：

• 透明数据加密（TDE）：
  • 作用：加密整个数据库的磁盘文件（静态数据），对应用完全透明——应用不需要做任何代码修改，连接数据库、读写数据的逻辑和之前完全一样。
  • 局限性：TDE只保护磁盘上的数据，当数据被加载到SQL Server内存中、或者通过查询返回给应用时，仍然是明文状态。如果你的合规需求仅针对静态数据防护（比如防止磁盘被盗导致数据泄露），TDE完全满足GDPR要求；但如果需要数据库存储和传输过程中都加密，TDE就不够了。

其他SQL Server内置加密方案都无法做到零应用修改：

• 列级加密（EncryptByKey/EncryptByCert）：需要应用显式调用解密函数才能获取明文，必然要修改Delphi 7的代码逻辑。
• Always Encrypted：依赖客户端驱动支持加密解密，而Delphi 7的老版本ODBC/OLEDB驱动大概率不支持这个较新的特性，无法使用。

二、你的开关参数方案：可行且低影响的实践路径 #

如果TDE无法满足你的完整加密需求（需要存储态加密且内存/传输中也防护），你提议的开关参数方案是非常务实的，能将应用改动降到最低，具体实施建议如下：

1. 数据库端准备 #

• 新增加密存储列：原密码列是char(32)（明文），建议新增两个列：
  • PasswordHash char(64)：存储加盐后的SHA2_256哈希值（GDPR推荐的强哈希算法，避免用MD5这类已被破解的算法）；
  • PasswordSalt char(16)：存储每个用户的随机盐（防止彩虹表破解，必须每个用户盐不同）。
    如果你倾向对称加密而非哈希，也可以新增EncryptedPassword varbinary(max)存储加密后的密码，但哈希+盐是密码存储的行业标准，比对称加密更安全（无法逆向解密明文）。
• 新增开关配置：可以在数据库中创建一个简单的配置表（如AppSettings），加一行EnableSecureAuth bit字段，或者直接在Delphi应用的配置文件中加开关参数，方便灵活切换。

2. 应用端修改（极小改动） #

• 认证逻辑分支处理：在用户登录的认证代码中，增加一个判断：
  • 当开关为false时：继续使用原逻辑，直接对比输入密码和数据库的明文Password列；
  • 当开关为true时：将输入密码和该用户的PasswordSalt拼接后，计算SHA2_256哈希，再和PasswordHash列对比（或者更简单：把输入密码传给SQL Server，让数据库端用HASHBYTES('SHA2_256', CONCAT(@InputPassword, @Salt))计算后对比，这样应用端甚至不需要实现哈希算法，改动更少）。

3. 数据迁移与过渡 #

• 先在开关关闭状态下，批量将现有明文密码转换为哈希+盐，存入新增的列中；
• 测试环境开启开关，验证认证逻辑正常后，再逐步在生产环境切换；
• 待所有用户数据迁移完成、开关稳定运行一段时间后，可以删除原明文Password列，彻底完成合规改造。

三、额外合规建议 #

• 即使开关未开启，也不要继续写入明文密码：新注册/修改密码的用户，直接写入哈希+盐值，逐步淘汰明文存储；
• 确保密码传输过程加密：Delphi应用连接SQL Server时，启用SSL加密连接，防止密码在网络传输中被截获；
• 不要硬编码加密密钥/盐的生成逻辑：密钥和盐的生成要随机、安全，避免固定值导致的安全风险。

内容的提问来源于stack exchange，提问作者advapi