is a GUID a good salt? is my register/login process got any flaw?

Question

If my table inside the database look like:

 userid uniqueidentifier
 username varchar(20)
 password varbinary(max)

When the user submit(to register), I send the user/pass to a stored procedure.

The stored procedure create a new GUID(Using NEWID()) then I use the HashBytes(sha1) function of SQL Server to create the password based on the GUID+password provided then I insert the values into the table above.

When the user submit(to login), I send the user/pass to a stored procedure.

The stored procedure look for the username and grab the userid to compare the hashbyte(sha1) of guid+password with the password field.

do you see any flaw inside that logic?

Answer 1

That's pretty standard - a guid would be fine for a salt. The point of a salt is to prevent Rainbow attacks, and pretty much any value that's random (or even if not random, then at the very least, different) for each user will do the trick.

Answer 2

If security is the primary concern, I'd rather NOT use a GUID for the salt value.

GUID's come in different "types", with some being more "random" than others. However, even the best type of GUID (this would be V4-type GUID's from a "randomness" perspective) are not really suitable for cryptographic functions.

From the Wikipedia article on GUID's:

V4 GUIDs use the later algorithm, which is a pseudo-random number. These have a "4" in the same position, for example {38a52be4-9352-453e-af97-5c3b448652f0}. More specifically, the 'data3' bit pattern would be 0001xxxxxxxxxxxx in the first case, and 0100xxxxxxxxxxxx in the second. Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given the initial state one can predict up to next 250 000 GUIDs returned by the function UuidCreate. This is why GUIDs should not be used in cryptography, e. g., as random keys.

Answer 3

As describe, it's not clear how the mechanism works - I assume the userid field contains the generated GUID (otherwise I don't see how you retrieve it for comparison).

There are different types of GUID, not all of them random. But then, randomness is not really required for password salting. All in all, your approach looks fine, though you might consider performing the hashing multiple times ("key strengthening") to improve security further.