Ответ 1

Я считаю, что pwdencrypt использует хеш, поэтому вы не можете действительно изменить хешированную строку - алгоритм разработан так, что это невозможно.

Если вы проверяете пароль, который пользователь вводил в обычную технику, это хеш файл, а затем сравнивайте его с хеш-версией в базе данных.

Вот как вы можете проверить введенную пользователем таблицу

SELECT password_field FROM mytable WHERE password_field=pwdencrypt(userEnteredValue)

Замените userEnteredValue (большой сюрприз) значение, введенное пользователем:)

Ответ 2

Алгоритм хэширования пароля SQL Server:

hashBytes = 0x0100 | fourByteSalt | SHA1(utf16EncodedPassword+fourByteSalt)

Например, для хеширования пароля "правильный скот для батареи лошади". Сначала мы генерируем некоторую случайную соль:

fourByteSalt = 0x9A664D79;

И затем хэш-пароль (закодированный в UTF-16) вместе с солью:

 SHA1("correct horse battery staple" + 0x9A66D79);
=SHA1(0x63006F007200720065006300740020006200610074007400650072007900200068006F00720073006500200073007400610070006C006500 0x9A66D79)
=0x6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

Значение, хранящееся в таблице syslogins, представляет собой конкатенацию:

[header] + [соль] + [хэш]
0x0100 9A664D79 6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

Что вы можете увидеть в SQL Server:

SELECT 
   name, CAST(password AS varbinary(max)) AS PasswordHash
FROM sys.syslogins
WHERE name = 'sa'

name  PasswordHash
====  ======================================================
sa    0x01009A664D796EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

• Заголовок версии: 0100
• Соль (четыре байта): 9A664D79
• Хэш: 6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3 (SHA-1 - 20 байт, 160 бит)

Проверка

Вы проверяете пароль, выполняя тот же хеш:

• возьмите соль из сохраненного PasswordHash: 0x9A664D79

и снова выполните хэш:

SHA1("correct horse battery staple" + 0x9A66D79);

который выйдет на тот же хеш, и вы знаете, что пароль правильный.

То, что когда-то было хорошо, но теперь слабое

Алгоритм хеширования, введенный с SQL Server 7 в 1999 году, был хорош для 1999 года.

• Хорошо, что пароль hash соленый.
• Хорошо добавить соль к паролю, а не добавить.

Но сегодня это устарело. Он только запускает хэш один раз, где он должен запускать его несколько тысяч раз, чтобы помешать атакам грубой силы.

В самом деле, Microsoft Baseline Security Analyzer будет, как часть проверки, пытаться использовать bruteforce пароли. Если он догадывается о них, он сообщает о слабых паролях. И он получает некоторые.

Принудительное принуждение

Чтобы помочь вам проверить некоторые пароли:

DECLARE @hash varbinary(max)
SET @hash = 0x01009A664D796EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3
--Header: 0x0100
--Salt:   0x9A664D79
--Hash:   0x6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

DECLARE @password nvarchar(max)
SET @password = 'password'

SELECT
    @password AS CandidatePassword,
    @hash AS PasswordHash,

    --Header
    0x0100
    +
    --Salt
    CONVERT(VARBINARY(4), SUBSTRING(CONVERT(NVARCHAR(MAX), @hash), 2, 2))
    +
    --SHA1 of Password + Salt
    HASHBYTES('SHA1', @password + SUBSTRING(CONVERT(NVARCHAR(MAX), @hash), 2, 2))

SQL Server 2012 и SHA-512

Начиная с SQL Server 2012, Microsoft переключилась на использование SHA-2 512-бит:

hashBytes = 0x0200 | fourByteSalt | SHA512(utf16EncodedPassword+fourByteSalt)

Изменение префикса версии на 0x0200:

SELECT 
   name, CAST(password AS varbinary(max)) AS PasswordHash
FROM sys.syslogins

name  PasswordHash
----  --------------------------------
xkcd  0x02006A80BA229556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B33DEC99FCF1A822393FC66226B7D38

• Версия: 0200 (SHA-2 256-бит)
• Соль: 6A80BA22
• Хэш (64 байта): 9556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B33DEC99FCF1A822393FC66226B7D38

Это означает, что мы кодируем пароль UTF-16 с суффиксом соли:

• SHA512 ( "правильный скот для лошадиных батарей" + 6A80BA22)
• SHA512 (63006f0072007200650063007400200068006f0072007300650020006200610074007400650072007900200073007400610070006c006500 + 6A80BA22)
• 9556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B33DEC99FCF1A822393FC66226B7D38

Ответ 3

Вы понимаете, что вы можете сделать стержень для своей спины на будущее. Параметры pwdencrypt() и pwdcompare() являются недокументированными функциями и могут не совпадать в будущих версиях SQL Server.

Почему бы не хэш-пароль с использованием предсказуемого алгоритма, такого как SHA-2 или лучше, прежде чем попасть в БД?

Ответ 4

Вы действительно не должны дешифровать пароли.

Вы должны шифровать пароль, введенный в ваше приложение, и сравнивать с зашифрованным паролем из базы данных.

Изменить - и если это связано с тем, что пароль был забыт, настройте механизм для создания нового пароля.

Ответ 5

Вы не можете снова расшифровать этот пароль, но есть еще один метод с именем "pwdcompare". Ниже приведен пример использования синтаксиса SQL:

USE TEMPDB
GO
declare @hash varbinary (255)
CREATE TABLE tempdb..h (id_num int, hash varbinary (255))
SET @hash = pwdencrypt('123') -- encryption
INSERT INTO tempdb..h (id_num,hash) VALUES (1,@hash)
SET @hash = pwdencrypt('123')
INSERT INTO tempdb..h (id_num,hash) VALUES (2,@hash)
SELECT TOP 1 @hash = hash FROM tempdb..h WHERE id_num = 2
SELECT pwdcompare ('123', @hash) AS [Success of check] -- Comparison
SELECT * FROM tempdb..h
INSERT INTO tempdb..h (id_num,hash) 
VALUES (3,CONVERT(varbinary (255),
0x01002D60BA07FE612C8DE537DF3BFCFA49CD9968324481C1A8A8FE612C8DE537DF3BFCFA49CD9968324481C1A8A8))
SELECT TOP 1 @hash = hash FROM tempdb..h WHERE id_num = 3
SELECT pwdcompare ('123', @hash) AS [Success of check] -- Comparison
SELECT * FROM tempdb..h
DROP TABLE tempdb..h
GO

Ответ 6

Быстрый google указывает, что pwdencrypt() не является детерминированным, а ваш оператор select pwdencrypt ('AAAA') возвращает другой значение при моей установке!

См. также эту статью http://www.theregister.co.uk/2002/07/08/cracking_ms_sql_server_passwords/