Re: Spoofing as the postmaster

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.

In my case, the reason I did it is because I was trying to navigate
around the US export control regulations that prevent greater than 1024
bit assymetric or 128 bit symmetric from leaving the US. I was able to
use the standard Java SSL and crypto libraries to achieve greater than
128 bit symmetric encryption by combining the two.

Now, my implementation isn't perfect with regard to Andrew's comments,
as I encrypt using the server's public certificate after authenticating
it. Technically, however, I could actually have two server certificates
- one to use for authentication, and one to use for encryption. I
believe this is becoming common in some circles, and you will find that
gpg uses DSA keys for authentication, and signs the RSA keys used for
encryption with the DSA key. The DSA key can be more bits, or have a
longer life time.

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.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>