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?
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.