5

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?

isekaijin
  • 19,076
  • 18
  • 85
  • 153

1 Answers1

15

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

Community
  • 1
  • 1
Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
  • @Matthew: I don't really understand how random salting works. How can I validate an user's password against a hash that includes a random salt? – isekaijin Mar 23 '11 at 21:59
  • 2
    @Eduardo, you store both the per-user salt and the hash in the database. Neither are really secret. Then, you hash the stored salt and supplied password and check the result against the stored hash. See [this article](http://wheelersoftware.com/articles/storing-passwords-securely-hash-salt.html). You can also search Stack Overflow for more information. – Matthew Flaschen Mar 23 '11 at 23:40
  • @Matthew: If these salts are actually saved in the database and associated with their respective users, what is the difference between using a random salt and using a non-public user-specific field (such as UserID, in systems in which UserID and UserName are separate fields) as the salt? – isekaijin Mar 23 '11 at 23:49
  • 1
    Just to clarify, the password should still be resistant to cracking even if the hash and salt are compromised. However, you still wouldn't deliberately disclose either. As far as a non-public key like UserId, that still facilitates the use of lookup tables. For example, small sites will tend to have low UserIds, so rainbow tables can be built specifically attacking salts from 1 to 1000. A random value is more secure. – Matthew Flaschen Mar 23 '11 at 23:53
  • 2
    @Eduardo, I wrote an article: http://dustwell.com/how-to-handle-passwords.html that explains the whole per-user salt thing in a bit more detail. – Dustin Boswell Mar 24 '11 at 00:31
  • @Matthew: You're right. But, at the company I work for, by policy, sensitive primary keys are always `UNIQUEIDENTIFIER`s. – isekaijin Mar 24 '11 at 00:34
  • 1
    @Eduardo, okay. NEWID doesn't return uniformly at random values, but I think it's *probably* "random enough." – Matthew Flaschen Mar 24 '11 at 01:00
  • Isn't it still better to send the hash? Just in case your own server is compromised and the user is reusing passwords. – Markus Aug 03 '12 at 06:58