Hash passwords before transmitting? (web)

views:

100

answers:

+2 Q:

Hash passwords before transmitting? (web)

I was reading this Ars article on password security and it mentioned there are sites that "hash the password before transmitting"?

Now, assuming this isn't using an SSL connection (HTTPS), a. is this actually secure and b. if it is how would you do this in a secure manor?

Edit 1: (some thoughts based on first few answers)

c. If you do hash the password before transmission, how do you use that if you only store a salted hash version of the password in your user credentials databas?

d. Just to check, if you are using a HTTPS secured connection, is any of this necessary?

+4 A:

This is only secure if the server sends a non-reusable salt (and, of course, if you use a secure hash).

Otherwise, the attacker can simply sniff the users hash, then replay the hash to log in as the user.

Note that the login is vulnerable to a man-in-the middle attack.

SLaks 2010-06-09 19:13:36

+1 Absolutely, if the hacker can simply re-post the hash to the server it's no more secure than a plaintext password.

Paolo 2010-06-09 19:15:22

@Paolo: At least the attacker cannot use the password on other sites.

SLaks 2010-06-09 19:19:27

So would this be a viable implementation (assuming javascript enabled): when the user submits, do an ajax call with a unique id for the request, server responds with non-reusable salt based on id, client browser uses SHA-1 (or better) to hash salt and password, and then transmit that to server which checks password, ajax id, username?

wag2639 2010-06-09 19:31:01

nevermind, that wouldn't work, I just read Thorarin post and comments and realized double hashing would be a problem. If you securely store as a salted hashed in your database, you wouldn't be able to use it with the ajax salt/hash unless you use some kind of decryptable hash.

wag2639 2010-06-09 19:35:30

@wag: Actually, it would work. There's nothing wrong with double-hashing. You can send both the (fixed) salt for the hash in the database and the (random) non-resuable salt, then hash the password on the client using the fixed salt, and hash the resulting hash using the random salt.

SLaks 2010-06-09 19:47:55

PS: A decryptable hash is called an encryption.

SLaks 2010-06-09 19:49:59

@Slaks, +1 for encryption (couldn't think of the word before), but as far as sending the database hash, I thought that should be kept as secret as possible (probably never used outside of the server)

wag2639 2010-06-09 20:00:04

@wag: I don't mean to send the database hash. I mean to send the database salt, so that the client can create the database hash by itself.

SLaks 2010-06-09 20:04:02

@Slaks, yeah thats what I meant, shouldn't the database salt be kept secret too? i currently use a double hash implementation for my database hashes, a unique string for each user plus a standard salt for the application that is kept secret. I read on an other StackOverflow question that the application salt should be kept secret.

wag2639 2010-06-09 20:37:22

@wag: There's nothing wrong with exposing the salt. Note that the salt should not be limited to ASCII characters.

SLaks 2010-06-09 21:01:22

+1 A:

I wouldn't call it secure, but it's better than nothing. If you let the server pick a hash salt every time a user logs in, that will protects against replay. However, there's nothing protecting users from man in the middle attacks while they are logged in.

You will have to store the salt you generated somewhere on the server while the user is logging in. If that is a problem, you could hash the salt with another (fixed) salt, use the result as a checksum and add both to your login form as hidden fields.

There are some JavaScript SHA-1 implementations around that should do the trick. Don't use MD5 if you can help it.

Thorarin 2010-06-09 19:16:05

+1 -- but it's not much better than nothing if you care about security at all.

tvanfosson 2010-06-09 19:23:54

@tvanfosson: one problem is that you end up having to store passwords in plain text, or use some kind of double hashing. The latter makes it rather complicated, with limited benefits.

Thorarin 2010-06-09 19:28:12

@thorarin - I'd be more concerned that Mallory would have generated a rainbow table based on the salt she's passing to Bob (or, since she's smart, several rainbow tables and with different salts) and will eventualy triangulate Bob's real password so she can use it in the future to talk with Alice.

tvanfosson 2010-06-09 19:31:37

What's wrong with double-hashing?

SLaks 2010-06-09 19:50:33

@tvanfosson: that is a concern, yes. Each new hash makes it more likely someone will be able to find the original password. If they tried hard enough :)

Thorarin 2010-06-09 19:55:12

You can protect this scheme against man-in-the-middle attacks by using the salted database hash to generate a secret key for symmetric encryption.

It would work like this:

Server looks up the password hash in the database H_D along with salt S_D
Server chooses a random salt S_R
Server generates a secret key K by hashing the database hash with S_R
Server sends S_D and S_R to the client

Client calculates H_D by hashing the user's password with S_D
Client calculates K by hashing H_D with S_P
Client encrypts all server communication with K

This scheme creates a random session key K based on the user's password.
A man in the middle would not be able to derive K without knowing the user's password (or H_D, which must be kept secret), and therefore cannot impersonate the server.

SLaks 2010-06-09 20:11:31

ansaurus

tags:

views:

answers:

Hash passwords before transmitting? (web)

related questions