I am in the process of evolving architecture for an 'equity analysis system'. I will be using SQLServer as the database, but I am not going the .NET route and won't be using the built-in 'membership' features. I have designed the user, user_credentials, roles and permissions tables. The 'credentials' table stores id, user f/l name, email, login id, salt, and hashed password.
The question is
a) Can the stored procedure inserting the values into the 'credentials' table do the hashing using the database's features - hashbytes/sha2_512? If so, the plain-text password needs to be passed as a parameter to the stored procedure which could be looked at by a DBA via Profiler or Tracing.
b) Should the application on the web-server, say node.js, create the salt and the hash and send only the hashes to the stored procedure thereby keeping the plain-text password completely invisible to the database? However, the passwords are still available for view at the web-server, should an admin decide to look at them.
I would like to keep the web/app server light-weight and do pretty much all the work on the database side and looks like option-a would be the way to go. At the same time, sophisticated algorithms such as bcrypt, scrypt may not be available from within the database and part of me says it is better to go with option-b. Also, it may not be the database's job to do the somewhat memory-intensive hashing work. I am sure the best practices would suggest using option-b.
I am deliberately not going the OpenID / OAuth 2.0 route. Nor considering using MySQL, PostgreSQL or any of the NoSQL databases, for now, as a lot of work has already happened in SQLServer.
Your thoughts, advice, suggestions, and pointers are much appreciated.