SQL Server - Storing Password

Question

I'm usually pretty cautious about storing sensitive information and prefer to use a Facebook / Twitter login where possible so they can handle the password. However I've reached a project where there is no option other than to store a username / password in the database and I wanted to ensure that my code that I'm using is flawless in terms of security.

I've written the procedure below which will generate the hashed password and plan to store the result of @strPassword and @strSalt against my users table.

The web site / mobile app will then hash the password and post it over a HTTPS connection to the web service which will combine the hashed result with the salt and hash it again obviously to compare it to the password stored in my table.

From the things I've read this should prevent rainbow tables being used to decrypt it, as well as using SHA512 which should prevent brute force, and finally over HTTPS which will prevent anything stealing the password in transit. And if a virus was on the client device that could save a copy of the password it would already be partially hashed.

Is there any potential flaws here or is there a better way to achieve this?

DECLARE @strPassword VARCHAR(128)
DECLARE @strSalt VARCHAR(36)
DECLARE @strHashMethod VARCHAR(10) = 'SHA2_512'

SET @strPassword = HASHBYTES(@strHashMethod, 'MyPassword')
SET @strSalt = CONVERT(VARCHAR(36), NEWID())
SET @strPassword = HASHBYTES(@strHashMethod, @strSalt + @strPassword)

SELECT CONVERT(VARBINARY(128), @strPassword)

Answer 1

Looks secure to me!

You could throw in an iteration count if you felt like it, e.g., loop this 100 times just before your final line:

SET @strPassword = HASHBYTES(@strHashMethod, @strPassword)

Alternatively, the IC (iteration count) could be a random int between, say, 100 and 1000, and stored alongside the hashed password and salt in the underlying table.

Slightly odd to use NEWID() to create the salt. I'd probably just use CRYPT_GEN_RANDOM(16).