On Tue, Jun 17, 2008 at 11:27 PM, Martin O'Neal
<martin.oneal@xxxxxxxxxxxx> wrote:
I'm not sure if hashing the password
on the client side would be best practice
(anyone have a strong opinion?) but it
seems effective.
The problem is that it is not effective, just cosmetic. It doesn't buy
you anything (other than a false sense of security).
If someone has compromised your SSL, they can change whatever you put
inside it. In this example, all an attacker has to do is amend the
javascript as it goes past and make it send the cleartext auth.
I think most people tend to think about SSL as if the protection it is
providing is permanent, that, if you're not compromised initially
(e.g. with an MITM attack or an application vulnerability) then you
are never going to be compromised. This is not strictly true, although
it is virtually true for almost everyone. An encrypted SSL session can
be stored, kept indefinitely, and broken... eventually. At that point,
whatever was in the session, including the password, will be known to
the attacker. I accept that this is a stretch (and a really big one),
but purely from that point it's better to not have the password in
clear. Of course, people that are concerned with this sort of problem
should really look into using multi-factor authentication.
For the same reason, people need to think in terms for how long
information needs to stay protected when choosing SSL key sizes and
ciphers.