Using hash of password with SSL

Question

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

Answer 1

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.

Answer 2

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.