Это потому, что вы сохраняете результат вызова функции HASHBYTES
в поле NVARCHAR
, когда вы должны сохранить его в VARBINARY
.
Вотобработанный пример, который показывает это:
CREATE TABLE UserHash
(
[Password_NVARCHAR] NVARCHAR(200),
[Password_VARBINARY] VARBINARY(20)
)
DECLARE @Password NVARCHAR(20) = 'Abcdefghijklmnop'
DECLARE @HashThis nvarchar(4000);
SELECT @HashThis = CONVERT(nvarchar(4000),@Password);
INSERT
INTO [UserHash]
(
Password_NVARCHAR,
Password_VARBINARY
)
SELECT HASHBYTES('SHA1',@HashThis),
HASHBYTES('SHA1',@HashThis)
SELECT *
FROM [UserHash]
Вот результат последнего оператора в этом коде: 
Как видите, NVARCHAR
Версия показывает что-то, чего вы не ожидаете, потому что результат вызова HASHBYTES
интерпретируется как текст, а не как последовательность байтов.
Если вы посмотрите на длину текста в Password_NVARCHAR
поле (например, выполнив SELECT LEN(Password_NVARCHAR) FROM [UserHash]
), вы увидите, что это возвращается как 10 .Поскольку NVARCHAR
хранит текст, используя 2 байта на символ, ваш 20-байтовый хэш отображается в виде строки из 10 символов.
ПРИМЕЧАНИЕ : В приведенном выше сценарии Iразмер Password_VARBINARY
соответствует размеру SHA1, согласно связанной документации для HASHBYTES
размер столбца должен соответствовать размеру используемого алгоритма хеширования:
Выходные данные соответствуют стандарту алгоритма: 128 бит (16 байт) для MD2, MD4 и MD5;160 бит (20 байтов) для SHA и SHA1;256 бит (32 байта) для SHA2_256 и 512 бит (64 байта) для SHA2_512
ASIDE : не хранить пароль как хеш, используйте Соленый хэш .