binary(64)可存储字符数咨询及数据库密码认证存储过程疑问

一、binary(64)类型的存储容量说明 #

binary(64)是固定长度的二进制数据类型，它存储的是64字节的二进制内容，而非直接按“字符”计数：

• 如果将其转换为十六进制字符串表示，64字节的二进制数据对应128个十六进制字符（每个字节可转换为2个十六进制字符）；
• 作为二进制存储时，它的容量是固定64字节，与字符编码无关，适合存储SHA2_512这类输出为64字节的哈希值。

二、现有存储过程的问题与优化 #

你的存储过程核心逻辑是对密码加盐后哈希验证，但存在几个可以优化的点：

1. 编码一致性问题 #

当前使用nvarchar类型拼接密码和盐，SHA2_512处理的是字节流，nvarchar是双字节编码，可能导致不同环境下的哈希结果不一致。建议统一转换为varbinary后再拼接：

declare @PasswordHash nvarchar(100)
    = 'ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|ThisIs101|'
DECLARE @salt UNIQUEIDENTIFIER = Newid();
declare @passwordHashBinary binary(64) = (
                                       select Hashbytes('SHA2_512', CONVERT(VARBINARY(MAX), @PasswordHash) + CONVERT(VARBINARY(36), @salt))
                                   );

if (@passwordHashBinary = Hashbytes('SHA2_512', CONVERT(VARBINARY(MAX), @PasswordHash) + CONVERT(VARBINARY(36), @salt)))
begin
    select 1
end
else
begin
    select 0
end

2. 密码长度上限说明 #

SHA2_512哈希函数支持任意长度的输入数据，所以密码长度上限不由哈希输出决定。你当前设置的100字符密码是合理的，若需要支持更长密码，只需调整前端输入限制和@PasswordHash的类型长度（比如改为nvarchar(256)）即可，哈希结果始终是固定64字节。

三、账号找回场景的优化方案 #

针对账号找回场景（不存储明文密码/答案），可以参考以下方案：

• 复用哈希加盐逻辑：对用户设置的找回问题答案，采用与密码相同的哈希加盐方式处理，将哈希值和随机盐一起存储在用户表中，验证时重新计算哈希对比即可；
• 每个用户独立存盐：不要使用全局盐，为每个用户生成唯一的随机盐（如NEWID()生成的UNIQUEIDENTIFIER），与哈希值关联存储，提升破解难度；
• 增加多因素验证：仅依赖找回问题安全性较低，建议结合短信验证码、邮件验证码等多因素验证方式，降低账号被恶意找回的风险；
• 限制答案复杂度：对找回问题答案设置长度、字符类型要求（如至少8位，包含字母数字），避免简单答案被暴力破解。

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