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

Why are you re-inventing login when you don't understand nonces?

1. Doing anything crypto-related is hard. Experts make mistakes which are missed by other experts for decades. The rest of us are even worse.
2. There are a large number of off-the-shelf authentication systems available for free. Nearly all of them will be better implemented and more flexible than something you roll yourself.

Update based on new details of question from comments. For a Windows GUI app talking to SQL Server, my authentication choices would start with:

1. Domain authentication (easy, but requires domains).
2. Cardspace. Not hard, very flexible, but requires client infrastructure.
3. SQL Server mixed mode authentication (easy, but inflexible).
4. Kerberos via SSPI (harder, but very configurable).

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.

Answer 4

As Craig Stuntz noted, you should not be trying to do crypto on your own. The defition of salt is here. As it says, this should be random, and your GUID may not be random, and therefore you may have information leekage, and decreased security. That being said, it depends on how much security you want for your system. If this is not a large application, then you may be able to get away with your current system.

Answer 5

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.