Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Should passwords be hashed in the client side using the hash(password + salt) method even if I’m using HTTPS? or should I just hash it when it arrives to SQL SERVER 2008 R2 with a built in function? Thank You.
Why would you hash in the client side? Is this a single page app written in Javascript? Even then, you must have some server side language connecting to a database (ASP.NET? PHP?). Do your salting and hashing on the server side. Client side smells bad to me … for some reason the salting/hashing procedure seems more prone to attack if you’ve got the logic and random generation happening client side. I can’t point to a specific attack – but it just seems like a needless thing to push to the client (unless perhaps you can’t get SSL).
It’s not particularly important whether you do it in your server side language or directly in the database. I prefer doing your calculations in the code, and then sending the final hash over to SQL. Using built in SQL Server functions is annoying and there’s problems between versions – and your code is forever locked away in Microsoft-land.
TL;DR Do it server-side, not client, and not in database directly. HTTPS is necessary if you want that plaintext password encrypted over the line before you send (definitely should).