Is sending a hashed password over the wire a security hole?

Question

I've come across a system that is in use by a company that we are considering partnering with on a medium-sized (for us, not them) project.

They have a web service that we will need to integrate with.

My current understanding of proper username/password management is that the username may be stored as plaintext in the database. Every user should have a unique pseudo-random salt, which may also be stored in plaintext. The text of their password must be concatenated with the salt and then this combined string may be hashed and stored in the database in an nvarchar field. So long as passwords are submitted to the website (or web service) over SSL, everything should be just lovely.

Feel free to rip into my understanding as summarized above if I'm wrong.

Anyway, back to the subject at hand. The WebService run by this potential partner doesn't accept username and password, which I had anticipated. Instead, it accepts two string fields named 'Username' and 'PasswordHash'. The 'PasswordHash' value that I have been given does indeed look like a hash, and not just a value for a mis-named password field.

This is raising a red flag for me. I'm not sure why, but I feel uncomfortable sending a hashed password over the wire for some reason. Off the top of my head I can't think of a reason why this would be a bad thing... Technically, the hash is available on the database anyway. But it's making me nervous, and I'm not sure if there's a reason for this or if I'm just being paranoid.

EDIT

I was confused by some of the comments below until I re-read my post.

In the original, I had the phrase "So long as passwords are submitted to the website (or web service) over plaintext, everything should be just lovely."

I swear that as I thought that I was thinking the term 'SSL'. For some reason I typed the word 'plaintext' instead. Wow.

Worst. Typo. Ever.

Answer 1

Its good to be paranoid when it comes to security, but in this case I dont think you have too much to worry about. The hash is strictly one way, so could never be converted back to a plaintext password. The receiving party will simply make a check that the hash value sent matches the hash value they have stored.

The only concern then is ensuring that no-one can eavesdrop on the hashed password during transmission, so something like SSL should be used. If someone were to sniff the username + hashed password in transmission it could be reused by an attacker.

Answer 2

Details aside, this is an easy question to answer:

You can make all the effort in the world but if you are not using SSL, your authentication process can EASILY be exploited.

Answer 3

There is no value on using the hashed password to send it to the service, given you'd still need a separate mechanism to secure the communication i.e. SSL

If the system accepts the hashed password, for all intends and purposes the hashed password is the password. If an attackers gets the hashed password, (s)he has access to the account without needing to figure out the original password.

One important issue with all the above, is that if the db is compromised & an attacker gets the hashed passwords, that means instant access to all the accounts through the said WebService, since as far as the WebService cares those are already the passwords.

I really suggest you take it to them & talk about it. It might be one of those things that some dev did & haven't gained the attention/priority to straight it out.