The fundamental problem is that the password (or its material) is sent through the encrypted SSL channel instead of being integrated into it. The SSL negotiation should use the password to (re)generate the shared secret. If the server doesn't have the password (or password derived bits), it won't be able to communicate with the client. Similarly for the client. Why does this matter? A Man In The Middle attack is more difficult to stage because the client can detect that the middle man has no knowledge of the password during the secret key negotiation phase. It is still possible for the MITM to guess the key (at chance) and depending upon the protocol, the MITM might be able to extract information about the password that allows better than chance guessing; this all depends upon the design of the protocol.
There are plenty of protocols out there both freely available and patented that solve this problem. The patent for Encrypted Diffie Hellman has just expired and ought to be used by everyone, now. The problem is that SSL hardware accelerators won't work as expected, since they take the server key and pass the client credentials (password or its derived material) back to the application server for login. With an updated (more secure system), the password verifiers will have to be pushed down into the hardware accelerators, which means the hardware accelerator will have to "know" about the users, keep a user database. IT nightmare. Plus, that accelerator is sitting at the network edge, so you've got all of the user/password verifier info residing in close proximity to the internet (and hackers).
I still think it's better than sending your password (material, verifier) over a channel to a remote server. Anyone can be tricked into doing it.
Slashdot Mirror
The fundamental problem is that the password (or its material) is sent through the encrypted SSL channel instead of being integrated into it. The SSL negotiation should use the password to (re)generate the shared secret. If the server doesn't have the password (or password derived bits), it won't be able to communicate with the client. Similarly for the client. Why does this matter? A Man In The Middle attack is more difficult to stage because the client can detect that the middle man has no knowledge of the password during the secret key negotiation phase. It is still possible for the MITM to guess the key (at chance) and depending upon the protocol, the MITM might be able to extract information about the password that allows better than chance guessing; this all depends upon the design of the protocol. There are plenty of protocols out there both freely available and patented that solve this problem. The patent for Encrypted Diffie Hellman has just expired and ought to be used by everyone, now. The problem is that SSL hardware accelerators won't work as expected, since they take the server key and pass the client credentials (password or its derived material) back to the application server for login. With an updated (more secure system), the password verifiers will have to be pushed down into the hardware accelerators, which means the hardware accelerator will have to "know" about the users, keep a user database. IT nightmare. Plus, that accelerator is sitting at the network edge, so you've got all of the user/password verifier info residing in close proximity to the internet (and hackers). I still think it's better than sending your password (material, verifier) over a channel to a remote server. Anyone can be tricked into doing it.