两者都不是。没有盐的哈希很容易受到彩虹表的攻击。另一方面,密码必须以明文形式提交,这使得它容易受到 SQL 跟踪。
我最近为我当前的项目研究了这个特殊问题,并最终决定使用加盐的 X.509 签名。您在数据库中创建证书并使用其私钥创建密码签名(+ 个性化 GUID salt)。即使盐以纯文本形式存储,生成的哈希也无法恢复为原始密码。
基本上,代码如下所示:
create function [dbo].[security_GetPasswordHash]
(
@Password sysname,
@Salt uniqueidentifier
)
returns binary(128) with schemabinding, returns null on null input as begin
declare @CertId int, @CertPwd sysname;
set @CertId = ...; -- Get your cert however you like it
set @CertPwd = ...; -- If your cert is encrypted with password, get it too
return SignByCert(
@CertId,
SignByCert(@CertId, @Password, @CertPwd) + cast(@Salt as binary(16)),
@CertPwd
);
end;
go
这样,即使知道私钥的密码也无法帮助攻击者反转哈希。而在你的认证存储过程中,你可以使用这样的代码来判断密码是否正确:
-- Try to validate the user
select @UserId = u.Id
from dbo.Users u
where u.LoginName = @Login
and u.PasswordHash = dbo.security_GetPasswordHash(@Password, u.PasswordSalt);
-- Special case of user existence - there may be a wrong password here, too.
if @UserId is null begin
-- The specified user either does not exist, or wrong password has been supplied.
set @Error = 51008;
set @Message = dbo.sys_FormatErrorMessage(@Error, @CultureId, default, default, default, default);
throw 50000, @Message, 1;
end;
尽管警告称使用证书时计算成本高昂,但即使在使用 2 年的笔记本电脑上,该算法也足够快。