pwdencrypt and pwdcompare

In SQL Server 2000 is not documented but used at check of passwords function: pwdencrypt and pwdcompare.
I have decided to check up compatibility of these functions for SQL Server 2005.
The first, that is evident, it that hash became twice shorter, that most likely consequence of refusal of case-insensitive passwords.
Nevertheless, old hash quite well pass check by new functions.
One more appreciable difference, it that hash the same password now always visually different.
In an example, the third inserted row contains hash, taken of result of execution pwdencrypt on SQL Server 2000 SP3a 8.00.944.

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

Results

(1 row(s) affected)
(1 row(s) affected)
Success of check ------------------- 1 (1 row(s) affected)
id_num hash ----------- ------------------------------------------------------ 1 0x01004A335DCEDB366D99F564D460B1965B146D6184E4E1025195 2 0x0100E11D573F359629B344990DCD3D53DE82CF8AD6BBA7B638B6 (2 row(s) affected)
(1 row(s) affected)
Success of check
-------------------
1
(1 row(s) affected)
id_num hash ----------- ------------------------------------------------------ 1 0x01004A335DCEDB366D99F564D460B1965B146D6184E4E1025195 2 0x0100E11D573F359629B344990DCD3D53DE82CF8AD6BBA7B638B6 3 0x01002D60BA07FE612C8DE537DF3BFCFA49CD9968324481C1A8A8FE612C8DE537DF3BFCFA49CD9968324481C1A8A8 (3 row(s) affected)

Excuse for my English. I shall be glad to hear remarks.

Published Wed, Apr 6 2005 6:14 by gladchenko
Filed under:

Comments

# Alexander Lozhechkin [MSFT]

Alexander Lozhechkin [MSFT]

Friday, April 15, 2005 10:25 PM by TrackBack

# re: pwdencrypt and pwdcompare

Thanx for the info

Friday, September 15, 2006 8:13 AM by Ashish

# re: pwdencrypt and pwdcompare

pwdencrypt and pwdcompare functions does not appear in BOL or In MS SQL Server 2000 SP4, any reason for that?

Tuesday, September 19, 2006 10:06 PM by Tarik

# re: pwdencrypt and pwdcompare

Very helpful...Thank you very much!

Thursday, October 12, 2006 11:51 AM by Kasim

# re: pwdencrypt and pwdcompare

I am very Happy to see password encryption methodolgy. Fentastic

Saturday, October 14, 2006 4:29 AM by Nikhil Chaturvedi

# re: pwdencrypt and pwdcompare

Great!!! Very helpfull

Thursday, November 16, 2006 7:15 AM by Folkert

# re: pwdencrypt and pwdcompare

excellent. you have effectively shown that these hash values from SQL Server 2000 are acceptable to SQL Server 2005.

Friday, November 17, 2006 6:33 PM by George

# re: pwdencrypt and pwdcompare

Alexander:

How difficult is guessing a password hashed with pwdencrypt?

Thursday, March 01, 2007 9:40 AM by Javier

# re: pwdencrypt and pwdcompare

2 Javier

It will strongly raise CPU utilization... (IMHO)

Friday, March 09, 2007 5:34 AM by gladchenko

# re: pwdencrypt and pwdcompare

An excellent entry, I did  reference to your blog, at one entry related to pwdencrypt and pwdcompare.

Regards.

Friday, March 09, 2007 11:12 AM by Teo Ortega

# re: pwdencrypt and pwdcompare

Alexander:

In my first message, I had forgotten to thank you for the information. I have been doing tests. Very interesting.

Friday, June 15, 2007 5:06 PM by javier752003@hotmail.com