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.

Oligoclase

He signed up (and later logged in) using the hash/salt - it's really his password. So the mechanism to retrieve the password is the same, it's just at at the client and not the server. Not much of a change. – Xeres

Something to add as a reference to this question: en.wikipedia.org/wiki/Host-proof_hosting – Dulsea

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.

Florie

Good comment - thanks. The benefit is that it means the user's "real" password remains completely secret - even from the server. So, if it's used for other activities (e.g. encryption), then you can safely know the server can't use it. I think that's an attractive feature. – Oligoclase

I don't think it will hinder security at all, assuming the hash of the password is typically longer and more random than the original password. – Florie

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.

Brandwein

Answer 3

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.

Blida

OK, interesting point. Yes, I guess perhaps my point is a little philosophical in that we could simply be malicious in the client software ;-). I think there is a benefit though: e.g. imagine a code-signed 3rd party client, written for the same service. Also, what do mean by hindrance? In terms of development, it's like, 4 lines of code. Hindrance in terms of complexity? Well maybe, but it's very easily testable. Or did you mean it's a hindrance to security? – Oligoclase

Answer 4

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.

Rimrock

Yes, as I said, I'm re-hashing the "hash" of the password before I store it in the DB (just like one would with using the original password). So the DB entry is doubly hashed. As people have pointed out, from the POV of the server it's transparent to the server what it's receieved, so it acts just like that is THE password – Oligoclase

Answer 5

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.

Toodleoo

I probably should have explained better that this is a client application not a web app. The user will enter his password as normal and it is re-hashed client side. – Oligoclase

Then while it may be a little a bit redundant, I would think it'd add some measure of security, especially if your attacker doesn't have your client. – Toodleoo

Well the attacker would have the client, but I'm not clear why that's a problem. The hashing algorithm wouldn't be secret (e.g. something SHA). Why is that relevant? The attacker would still need to a) know the hash of the password and b) reverse it back to the original password – Oligoclase