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