Mark Mielke wrote: > Andrew Sullivan wrote: >> On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote: >> >>> I don't follow. What are banks doing on the web now to force clients >>> to authenticate them, and how is it any different from the model of >>> training users to check the SSL certificate? >>> >> >> Some banks (mostly Swiss and German, from what I've seen) are requiring >> two-token authentication, and that second "token" is really the way that the >> client authenticates the server: when you "install" your banking >> application, you're really installing the keys you need to authenticate the >> server and for the server to authenticate you. >> > I have done this for my own application before. Although the client and > server use standard TLS 1.0 to speak to each other with a required > authentication of RSA 1024-bit and a required encryption of AES 128-bit, > it still requires that passwords sent from the client to the server are > RSA encrypted using the server public certificate, making it impossible > for anybody except for the legitimate server to see the password. One > benefit of this is that the password itself can be '\0'd out as soon as > we have RSA encrypted it, and things like a core dump of the client have > a lower chance of including the password in plain text.
Why are you even using a password in this case, and not just key-based auth? Wouldn't that be even easier and more secure? > At what point does prudence become paranoia? I don't know. In my case, I > felt 128-bit encryption was insufficient for protecting the passwords in > my application. 256-bit encryption would have been sufficient, but that > cannot yet be safely exported from the US to the countries I required. How do you protect the certificate store on the client? Or the binary that ends up prompting for the password on the client? //Magnus ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend