Using hash of password with SSL

OK this might sound like a strange question. Please read carefully before jumping on me OK? ;-)

Imagine this situation:

1. We have a server and a client.
2. They connect using SSL.
3. Client creates account on server with password.
4. But, what he actually passes to server over the wire is the hash (+salt) of the password (NOT the password)
5. Server saves this received hash of password in DB (hashed AGAIN with salt)
6. At logon time, to authenticate, user re-sends hash of password (NOT the password!).

OK, so yes, I realise this sounds strange. Yes the whole conversation is in SSL, so you COULD just send password plaintext. And yes, I realise one can store the plaintext password safely in a hashed form.

Here is the point I'm driving at: it is useful for our business to genuinely say "We will never know your password".

Note I'm NOT saying "we don't store your password in plaintext", but that we really, never, ever know it; you never give it to us.

(The reason for wanting this is not relevant, sufficed to say that user's password is used for other stuff, e.g. file encryption).

Yes, I realise you might say that with the normal way of doing this "well the password would only in plaintext in memory for 5ms while you do the hashing", but this is more about deniability. i.e., We can say 100% we don't even receive your password.

OK so here's the question:

• Has anyone done or heard of this kind of thing before?

• What are the safety implications of doing this?

I'm struggling to see a downside. For example:

• No replay attacks (since the conversation is encrypted using SSL an attacker can't see the hash)
• Can't look in the DB because the hash is itself, erm..., hashed

OK you may now jump on me :)

Thoughts, comments welcome.

Thanks,

John

Update: Just wanted to clarify: I'm not proposing that this is somehow an improvement to the security of the authent开发者_开发知识库ication process. But, instead that it allows the user's "real" password to remain secret, even from the server. So, if the real password is used for, say, encrypting files, the server doesn't have access to that.

I'm completely satisfied in my reasons for wanting this, the question is whether it is a hindrance to the security of the authentication process.

Consider a few things:

1. Something on the client side must decide on a salt and hash.
2. Whatever creates the hash in (1) is likely going to be easy for an attacker to discover
3. That salt and hash must be consistent. If the salt changes, so will the hash, and then your server won't be able to hash it back to the original.
4. That salt + hash have essentially become the user's new password.
5. If their original password was longer than the salt + hash, you may have just reduced the security of their password (assuming a good password and ignoring hash collisions).
6. But, if they have a poor password, you may have just increased the quality of their password (ignoring hash collisions and 1 and 2 above), sort of.

The end result is that the salt + password has become their new password. Overall, I agree with most people, there's little benefit in doing this.

It seems to me that there is one benefit to this scheme that I didn't see mentioned (maybe I missed it). One can certainly argue that the hash+salt becomes the real password. However, in terms of security for people who re-use passwords, it adds value. If I use my password of 'asdfasdf' with your site and someone compromises your server, they will not be able to extract my password that I use at dubdubdub.superfinance.com.

This is exactly what password hashers do for web-browsers.

The problem everyone has with your idea is not that it's a bad idea; it's just that, since you are the developer for both the client and server, trusting the client's computer but not the server does not give you any real benefit (the client, after all, could have a keylogger or something). So to answer your question: it is only a hindrance to you.

Another problem in addition to those mentioned above: Unless you hash and salt the received value again, you are essentially storing all your passwords in the clear. Any attacker who gets read access to your database can trivially authenticate as any user at all.

So at this point, really it doesn't help at all. Lets assume that somehow your SSL has been compromised. They sniff the hashed + salted password. Then they can just send that as your server is accepting the hashed+salted password as their password. What you're doing is just adding a single layer of complexity (not being able to enter the password in your password box) in which case they can manually POST it to your server.

Not to mention if it's done client side you're handing them not only your hashing algorithm, but your salt and how you combined it.

Summary: No great benefit in my mind, I may be wrong though.

I personally implement the hashing+salting server-side and force SSLv3/TLSv1 on login pages.