You're right, the client side CC is just another alternative if you're
worried about passwords being in clear text. If you have Client side
certs you can probably even do away with authentication as only
specific users will have the cert, though most places have the cert
and the login form as well to protect against the cert being stolen.

The SSL , yes will end at the Web server..but hey that is what it is
supposed to do. The deal though is - If you have a salted hash
mechanism with the salt controlled at the server, the password will
still be encrypted ...NOT by the SSL but because of the salt and the
MD5/SHA1 you are using on the client side to encrypt it.

The Client side code in this case won't be bypasssed. Well, I mean you
can of course intercept and remove the Javascript but the server won't
accept a request without a valid salted password hash..so you should
be fine. A lot of apps I've seen do this.

Lastly if you're concerned with the traffic between the WebServer and
the DB, you'll want to ensure that all your queries are also sent over
SSL(You'll probably need to enable this on the DB first). Incase your
app server(Tomcat/Weblogic etc) if at all you have one is on a
separate server , you'll need to look at encrypting content between:

a)Client and the WS
b WS and the AS
c)AS and the DB

Hope that clarifies things a little more.

Cheers
Arvind

On Tue, Sep 8, 2009 at 10:50 AM, Chintan Oza<chintan.oza (at) gmail (dot) com [email concealed]> wrote:
> Hi Arvind,
>
> There are 1 set of users for which password verification is done by
> over server where as in case of other group of users the password
> verification will be done by a third party system which expects
> password in the plain format.
>
> Correct me if I am wrong but usage of client certificate doesnt help
> protect communication between web server and app server as its job
> ends at web server which handles ssl.
>
> Thanks,
>
> Chintan

[ reply ]