Decrypt Encrypted Password

With the 0x prefix SQL Server indicates that the value is of the data type (Var)binary. - This is expected.

The completely different return value for the hashing of @pPassword must have a reason outside of the shown code. I would guess, that the value of @pPassword is different from the assumed value of 'joseph'.
 
I replaced @pPassword with 'joseph' in my sproc and got the hash that all of the online converters agree is correct. This means that I cannot trust the passing of the string into the @pPassword parameter of my SqlServer sproc. So, sonic8, your guess is correct. This is most disappointing. What can I do to ensure the @pPassword parameter will contain the string that I serve to it?
 
No. I took the salt out of my process for now until I get the basic hash to work. It shouldn't need salt, correct? Salt just adds another layer of security. I will add that back in once I get the basic hash to work.
 
Here is a pretty decent overview writeup on encryption, hashing, and salting.

No, you don't need a SALT value for testing.
Yes, your probably want a SALT value for the case where you are hashing simple passwords.

www.comparitech.com

Encryption, hashing, salting: What's the difference and how do they work

Encryption, hashing and salting are all important parts of cryptography. Learn what they are, how they work and the key differences between them.
www.comparitech.com www.comparitech.com
 
From the article:

Hashing functions in action​

Now that you understand what hash functions are, it’s time to put them into practice. If we put the same text of “Let’s eat” into an SHA-256 online calculator, it gives us:

5c79ab8b36c4c0f8566cee2c8e47135f2536d4f715a22c99fa099a04edbbb6f2
Click to expand...
If you type "Let's eat" into the suggested online calculator you will not get the hash that the author claims. However, if you copy and paste "Let's eat" from the article into the calculator it will return the promised hash. The author gives no explanation for this.
 
The author of the article uses a different character as an apostrophe than you do.
 
TheSearcher said:
What can I do to ensure the @pPassword parameter will contain the string that I serve to it?
Click to expand...
This should be the default and shouldn't need to be explicitly ensured.

Can you post the stored procedure's parameter definition and your code calling the SP?
 
What is the reason for the online converter here?

I ask because you originally post about hashing your password using SHA512, but link to an online converter using SHA256.
 
@cheekybuddha - The online converter was referenced by the author in the article posted by DocMan. I just wanted to point out the frailties of hashing strings. If someone can use:
a different character as an apostrophe than you do
Click to expand...
then all bets are off in so far as validating encrypted passwords is concerned.

@sonic8 - I will post that shortly. Thank you.
 
@sonic8 - Below is the sproc. I call it with:
Code: 
exec uspAddUser 'jsmith','joseph','John','Smith','0'

Code: 
USE [Notes_TEST]
GO
/****** Object:  StoredProcedure [dbo].[uspAddUser]    Script Date: 7/26/2024 10:06:39 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[uspAddUser]
@pLogin NVARCHAR(50),
@pPassword NVARCHAR(50),
@pFirstName NVARCHAR(40) = NULL,
@pLastName NVARCHAR(40) = NULL,
@responseMessage NVARCHAR(250) OUTPUT
AS
BEGIN
SET NOCOUNT ON

print @pPassword

DECLARE @salt UNIQUEIDENTIFIER=NEWID()
BEGIN TRY
-- WITH SALT
--INSERT INTO dbo.[User] (LoginName, PasswordHash, Salt, FirstName, LastName)
--VALUES(@pLogin, HASHBYTES('SHA2_512', @pPassword+CAST(@salt AS NVARCHAR(36))), @salt, @pFirstName, @pLastName)

-- WITHOUT SALT
INSERT INTO dbo.[User] (LoginName, PasswordHash, FirstName, LastName)
VALUES(@pLogin, HASHBYTES('SHA2_512', @pPassword), @pFirstName, @pLastName)

SET @responseMessage='Success'
END TRY
BEGIN CATCH
SET @responseMessage=ERROR_MESSAGE()
END CATCH
END

--Sproc creates 0x866D9B1682FB5DB56DDD860C95D03447B7120B8E66481DA9FE65AC1FA85C0BEB36F0D1C653E3EE97E832C0D753263CBC8140CAD3F0881921A5E18DC8D93DE541
-- as the PasswordHash
-- while this code:
-- declare @pPassword as varchar(50) = 'joseph'
-- select HASHBYTES('SHA2_512', @pPassword)
-- creates 0x24D6EDB8DBE2BCA27CFEFC1B0682BB7C34A0F5AA23EC6EA2724CC0DBFDBB9EB3D6BC90FEA92B84C0820DB784319ED53E6FB5DE74B19C36FEDE0C594D374792CD

Why are they different?
 
TheSearcher said:
@sonic8 - Below is the sproc. I call it with:
Code: 
exec uspAddUser 'jsmith','joseph','John','Smith','0'

Code: 
USE [Notes_TEST]
GO
/****** Object:  StoredProcedure [dbo].[uspAddUser]    Script Date: 7/26/2024 10:06:39 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[uspAddUser]
@pLogin NVARCHAR(50),
@pPassword NVARCHAR(50),
@pFirstName NVARCHAR(40) = NULL,
@pLastName NVARCHAR(40) = NULL,
@responseMessage NVARCHAR(250) OUTPUT
AS
BEGIN
SET NOCOUNT ON

print @pPassword

DECLARE @salt UNIQUEIDENTIFIER=NEWID()
BEGIN TRY
-- WITH SALT
--INSERT INTO dbo.[User] (LoginName, PasswordHash, Salt, FirstName, LastName)
--VALUES(@pLogin, HASHBYTES('SHA2_512', @pPassword+CAST(@salt AS NVARCHAR(36))), @salt, @pFirstName, @pLastName)

-- WITHOUT SALT
INSERT INTO dbo.[User] (LoginName, PasswordHash, FirstName, LastName)
VALUES(@pLogin, HASHBYTES('SHA2_512', @pPassword), @pFirstName, @pLastName)

SET @responseMessage='Success'
END TRY
BEGIN CATCH
SET @responseMessage=ERROR_MESSAGE()
END CATCH
END

--Sproc creates 0x866D9B1682FB5DB56DDD860C95D03447B7120B8E66481DA9FE65AC1FA85C0BEB36F0D1C653E3EE97E832C0D753263CBC8140CAD3F0881921A5E18DC8D93DE541
-- as the PasswordHash
-- while this code:
-- declare @pPassword as varchar(50) = 'joseph'
-- select HASHBYTES('SHA2_512', @pPassword)
-- creates 0x24D6EDB8DBE2BCA27CFEFC1B0682BB7C34A0F5AA23EC6EA2724CC0DBFDBB9EB3D6BC90FEA92B84C0820DB784319ED53E6FB5DE74B19C36FEDE0C594D374792CD

Why are they different?
Click to expand...
Did you forget to add the salt in your test? The SPROC uses a salt, but your SELECT test didn't?
 
The salt in my sproc is commented out. I have two options in the sproc: salt and no salt. I tried them both.
 
TheSearcher said:
The salt in my sproc is commented out. I have two options in the sproc: salt and no salt. I tried them both.
Click to expand...
I see, so what do you get if you simply do something like?
Code: 
 SELECT HASHBYTES('SHA2_512','joseph')
Just curious...
 
Last edited:
It could be a difference in the encoding of your password.
Your stored procedure uses NVARCHAR, in your test you use VARCHAR.
That results in different bytes which are sent to HASHBYTES I expect (have no time for tests right now), so the result between both calls can vary.
 
theDBguy said:
I see, so what do you get if you simply do something like?
Code: 
 SELECT HASHBYTES('SHA2_512','joseph')
Just curious...
Click to expand...
I just gave it a try, and this is the result I got.

0x24D6EDB8DBE2BCA27CFEFC1B0682BB7C34A0F5AA23EC6EA2724CC0DBFDBB9EB3D6BC90FEA92B84C0820DB784319ED53E6FB5DE74B19C36FEDE0C594D374792CD
 
You must log in or register to reply here.

Similar threads

M
Solved Password Validation sub
2
Replies
31
Views
627
mikenyby
M
D
Solved Change password using tempvar not passing to following form
Replies
4
Views
180
Gasman
Gasman
Pyro
MS Access to Azure SQL Connection String Variables
Replies
1
Views
264
sonic8
S
D
Solved Unbound form required using VBA
Replies
9
Views
498
Pat Hartman
P
O
Using MsAccess in Combination with PHP and MySQL: security
Replies
3
Views
858
sonic8
S

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top Bottom