Re: Spoofing as the postmaster

Magnus Hagander wrote:
> Mark Mielke wrote:
>
>>
>> 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?
>

Users of this product don't have keys - they have passwords. The
username/password is for per-user authentication. The username defines
the access level. Many users will use the same client. The client does
have its own private RSA key and public certificate, however, this
grants entry to the system. Password login is still required by the
users of the client.

>> 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
The certificate on the client grants access to the system. It does not
grant access to the resources on the system. Two-level authentication
with mandatory server authentication. You see similar things in physical
security instances. A security badge lets you in the door - but you
still need to login to the computer once you get in.

As for protecting the binary that prompts for a password on the client -
I didn't bother with this, although Java does allow for signed jar files
that would allow the user to be assured that the client is legitimate.
There are always loops though, just because the client is legitimate
doesn't mean that the keyboard is, and so on. You end up putting in
enough effort to mitigate the risk. The risk always exists, but through
clever, cryptographic, or obfuscatory measures, the risk can be greatly
reduced.

Cheers,
mark

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