Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 New to SQL Server Programming
 Create Hashed password and salt from text password

Author  Topic 

stegothdump
Starting Member

9 Posts

Posted - 2012-01-17 : 07:10:47
I've been banging my head against a wall on this one...written the following SQL:

DECLARE @Salt NVARCHAR(MAX)
EXEC dbo.sp_GenerateRandomString 8, @Salt OUTPUT


UPDATE RegisteredUsers
SET NopPassword =SUBSTRING(UPPER(master.dbo.fn_varbintohexstr(CAST(HASHBYTES('SHA1', Password + @Salt)as varbinary ))),0,40), PasswordSalt = @Salt

I have 2 main issues with this..


1. The @Salt output is only being run once and everypassword is getting the same Salt random string, how can i get this to run for every row?
2. Noppassword is coming out wrong...I'm getting 0X66282D0024753D447401600362C9E55213DEA (exmaple) where if i use an online tool to generate the hash ([url]http://www.tools4noobs.com/online_php_functions/sha1/[/url]) i get the correct value - 28ea10d764bf99d5cce7564e6ea410ea119fc5e7

Getting very confused on this one...if i dont use the function fn_varbintohexstr the output is weird symbols...

Cany anyone shed any light?

S

Kristen
Test

22859 Posts

Posted - 2012-01-17 : 07:15:16
Why not use some attribute of the record for the SALT (e.g. an IDENTITY column, or the PK value - if it never changes)? You are storing the SALE in [PasswordSalt] column anyway.

If you want random values in a set-based process like UPDATE then using NewID() to get a GUID (per row processed) is the only Random method that I know of.
Go to Top of Page

stegothdump
Starting Member

9 Posts

Posted - 2012-01-17 : 07:54:56
Hey there, managed to sort out the @Salt output but using a cursor...the ONLY issue i have is the HASHBYTE.

If i just use "HASHBYTES('SHA1', Password + @Salt" the output i get it weird symbols...when i try to CAST i get a HEX value instead the HASHED value, this also happens when i use convert??

Closest i get is - 0X66282D0024753D447401600362C9E55213DEA

But i should be - 28ea10d764bf99d5cce7564e6ea410ea119fc5e7

Thanks for looking...

S
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2012-01-17 : 08:33:45
Note that the return datatype from HASHBYTES is varbinary(8000), you are casting it as "varbinary" with no size, I don;t know what the default is but I personally would want to explicitly state the size I wanted - but truncating it is going to be risky anyway, isn't it?

Why not change your [NopPassword] column to be VARBINARY datatype, rather than VARCHAR ? then you can store it natively.

"managed to sort out the @Salt output by using a cursor."

I suppose that's OK if its a one-off, but otherwise cursors are slow and will not scale well.

"But i should be - 28ea10d764bf99d5cce7564e6ea410ea119fc5e7"

Including the specific random SALT that was generated for your test case?

Does it matter if it is repeatable?
Go to Top of Page

stegothdump
Starting Member

9 Posts

Posted - 2012-01-17 : 08:57:21
Thanks for the reply Kristen...yeah the cursor is fine, its a one off script that i will run (once i get it right!)

Without any conversion the output of the HASBYTES is "‰~S´�£ U Æ[ÀP¹ÄJ�"

The whole reason I am trying to do this is to match up to a new ecommerce system, they use a Hashed password and Salt Key. Saly Key is fine it just getting the hashed version of the password that's giving me the headache.

TIA.

S


Go to Top of Page

stegothdump
Starting Member

9 Posts

Posted - 2012-01-17 : 09:13:26
As an example...

taking the password "Test123" and the random Salt "w$[}Q[XP" my output in SQL is = 95F70A3A5315E5E378CA92FA0874448CA88FCCF8 (this is incorrect)
using the online tool above i get 61f3a492d67af333d930e936e305c1ab66308543 (this is correct), how can these be different?

S
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2012-01-17 : 09:29:31
Ah, I see, you are trying to generate it to be the same as a 3rd party package.

NVARCHAR will have two-bytes-per-character, which presumably HASHBYTES() will include in the calculation.

If you just want to process ASCII characters use VARCHAR definition [i.e. for Password and SALT] instead of NVARCHAR

NOTE: you may get a different result, compared to the 2rd party app, if a password includes "£" or similar ASCII characters outside the 32-127 range. You might want to check that no passwords include such characters, but beware that the Collation you use may well "disguise" attempts to find them using Regular Expressions and LIKE ...
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2012-01-17 : 09:39:27
Finding non-ascii cahracters in a column:
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=164618
Go to Top of Page

stegothdump
Starting Member

9 Posts

Posted - 2012-01-17 : 11:54:45
Thanks Kristen, by changing all of the fields involved to VarChar its all wokring as it should, thanks for the pointer on this one!

Cheers,

S
Go to Top of Page
   

- Advertisement -