Is it necessary to hash passwords before sending them over HTTPS?

Question

I'm new to both Web development (started this January) and Web security (started less than a week ago!), so please excuse me if my question is grossly uneducated, misinformed or plain simple stupid.

The company I work for's main product is a good old-fashioned client/server system. To make it more appealing to our customers, I've been given the task of developing a bunch of simple-task-centric Web applications that complement the system's whole-business-process-centric design. For example, if an user's role in the organization consists in approving purchase orders and payment orders, they might find it easier to use the WebApprovals application than opening both the Purchases and Treasury modules, and using them to approve purchase orders and payment orders, respectively.

Needless to say, all my Web applications have a login page. And, of course, I need them to be secure. For that reason, by design, these Web applications can only be used over HTTPS, never over plain HTTP.

Now, I would like to know how secure it is to send passwords over HTTPS without any further security measures. Is it secure enough? What do people with experience in the security field have to say?

Answer 1

HTTPS will handle transport security, so there is no reason to hash them on the client side. If you do so, the hashed password essentially becomes the real one, from the server's point of view. If someone steals your database, each row would then have the value the server expects to receive over the network. The attacker can simply create a new client that sends the hash directly without bothering with any real hashing.

However, the password sent over the network should never be stored in the database. Rather, there should be a per-user random salt. This should be used to hash the password server-side.

See Salting Your Password: Best Practices?.